spiderly 19.11.9 → 19.12.1

package/lib/directives/spiderly-filter-template.directive.d.ts

@@ -0,0 +1,34 @@
+import { TemplateRef } from '@angular/core';
+import type { FilterHandle } from '../filters/filter-store';
+import * as i0 from "@angular/core";
+/**
+ * Context handed to a filter template: the filter's handle, and nothing else it does not already
+ * carry. Read it with `let-f` and drive the filter through it — `f.value()` is the draft the
+ * control shows, `f.set(...)` writes one, `f.commit()` applies it.
+ */
+export interface FilterTemplateContext {
+    $implicit: FilterHandle;
+}
+/**
+ * Renders the editor for ONE filter of a `spiderly-data-table`'s bar, replacing the control the
+ * bar would have drawn for that filter's kind. Bind it to the filter's id; filters with no
+ * matching template keep the built-in control, so a table opts in one filter at a time.
+ *
+ * This is the narrow job the directive has. Placing a filter ANYWHERE else — a drawer, a modal,
+ * a header cell — needs no directive at all: `store.get(id)` returns the same handle and depends
+ * on nothing in the component tree, which is why the store is the consumer's to own.
+ */
+export declare class SpiderlyFilterTemplateDirective {
+    readonly template: TemplateRef<FilterTemplateContext>;
+    /** The id of the filter whose control this template renders. */
+    filterId: string;
+    constructor(template: TemplateRef<FilterTemplateContext>);
+    /**
+     * Without this the `let-` variable is `any` at every consumer, however well the context is
+     * declared — a directive's injected `TemplateRef<C>` never reaches the template that declares
+     * it. Same mechanism as `SpiderlyCellTemplateDirective`.
+     */
+    static ngTemplateContextGuard(dir: SpiderlyFilterTemplateDirective, ctx: unknown): ctx is FilterTemplateContext;
+    static ɵfac: i0.ɵɵFactoryDeclaration<SpiderlyFilterTemplateDirective, never>;
+    static ɵdir: i0.ɵɵDirectiveDeclaration<SpiderlyFilterTemplateDirective, "ng-template[spiderlyFilterTemplate]", never, { "filterId": { "alias": "spiderlyFilterTemplate"; "required": false; }; }, {}, never, never, true, never>;
+}

package/lib/directives/spiderly-overflow-title.directive.d.ts

@@ -0,0 +1,33 @@
+import { OnDestroy } from '@angular/core';
+import * as i0 from "@angular/core";
+/**
+ * Puts a native `title` on an element while its text is clipped — measured when the pointer
+ * arrives, which is the only moment a native title can surface.
+ *
+ * The data table clamps a default cell to one line (see the `.cell-text` rule), which hides the
+ * value and, before this, offered nothing to read it with — the reason PACMS hand-added `[title]`
+ * on four cells of one grid. Wrapping the column is a choice someone makes; this covers the
+ * default nobody touched.
+ *
+ * Native `title`, never `pTooltip`: it needs a deliberate hover rather than firing as the cursor
+ * crosses a dense list, which is what got the SKU tooltip removed.
+ *
+ * **Measured on hover, not watched.** The first shape ran `ngAfterViewChecked` on every instance
+ * every change-detection cycle (reading `textContent`, which allocates a fresh string each call)
+ * and gave each instance its OWN `ResizeObserver`. On a 100-row grid nineteen columns wide that is
+ * ~1900 hooks per cycle and ~1900 observers in Chrome's per-frame loop — all to decide something
+ * that can only ever be seen one cell at a time. Hover is exactly-in-time, costs nothing until it
+ * happens, and needs no separate handling for a column drag or a resized window: the next hover
+ * re-measures. Nothing is lost for a screen reader either — CSS clipping never hid the text from
+ * the accessibility tree, so the title was only ever a sighted-hover affordance.
+ */
+export declare class SpiderlyOverflowTitleDirective implements OnDestroy {
+    private readonly el;
+    private readonly zone;
+    private readonly onPointerEnter;
+    constructor();
+    ngOnDestroy(): void;
+    private sync;
+    static ɵfac: i0.ɵɵFactoryDeclaration<SpiderlyOverflowTitleDirective, never>;
+    static ɵdir: i0.ɵɵDirectiveDeclaration<SpiderlyOverflowTitleDirective, "[spiderlyOverflowTitle]", never, {}, {}, never, never, true, never>;
+}

package/lib/entities/filter-rule.d.ts

@@ -1,16 +1,14 @@
 import { MatchModeCodes } from '../enums/match-mode-enum-codes';
+import { AllowedOperatorFor } from '../filters/allowed-operators';
 /**
  * Represents a filter rule used for querying or filtering data collections.
  *
  * The `FilterRule` class is a generic structure that defines a single filtering condition,
  * including the match mode (comparison operator), the value to compare, and an optional logical operator.
  *
- * The allowed match modes are determined by the type parameter `T`:
- * - For `string`: supports `Contains`, `StartsWith`, and `Equals`.
- * - For `boolean`: supports `Equals`.
- * - For `Date`: supports `Equals`, `GreaterThan`, and `LessThan`.
- * - For `number`: supports `Equals`, `GreaterThan`, `LessThan`, and `In`.
- * - For other types: allows any value from `MatchModeCodes`.
+ * The allowed match modes are determined by the type parameter `T`, each union derived from the
+ * one operator table in `filters/allowed-operators.ts` (for other types, any `MatchModeCodes`
+ * value is allowed).
  *
  * @template T The type of the value to filter by.
  */
@@ -19,5 +17,5 @@ export declare class FilterRule<T = any> {
     value: T;
     operator?: string;
 }
-type AllowedMatchModes<T> = T extends string ? MatchModeCodes.Contains | MatchModeCodes.StartsWith | MatchModeCodes.Equals : T extends boolean ? MatchModeCodes.Equals : T extends Date ? MatchModeCodes.Equals | MatchModeCodes.GreaterThan | MatchModeCodes.LessThan : T extends number ? MatchModeCodes.Equals | MatchModeCodes.GreaterThan | MatchModeCodes.LessThan | MatchModeCodes.In : MatchModeCodes;
+type AllowedMatchModes<T> = T extends string ? AllowedOperatorFor<'text'> : T extends boolean ? AllowedOperatorFor<'boolean'> : T extends Date ? AllowedOperatorFor<'date'> : T extends number ? AllowedOperatorFor<'number'> : MatchModeCodes;
 export {};

package/lib/filters/allowed-operators.d.ts

@@ -0,0 +1,24 @@
+import { MatchModeCodes } from '../enums/match-mode-enum-codes';
+/**
+ * What each value type may be asked — the ONE operator table, mirroring what the generated
+ * paginator implements per type (`PaginatedResultGenerator`): `In` on a string column answers
+ * with InvalidMatchMode, PrimeNG's own text list adds three modes the backend 400s, and so on.
+ *
+ * Deliberately a LEAF module (imports nothing but the codes) so every consumer can derive from
+ * it without a cycle: the store's runtime validation and offered lists (`filter-store.ts`), the
+ * compile-time `FilterRule.matchMode` union (`entities/filter-rule.ts`), and the data view's
+ * kind-level lists (via `operatorOptionsForKind`). These used to be hand-kept copies; edit the
+ * table here and every surface follows.
+ *
+ * Tuple order is DISPLAY order for every operator picker (Equals, then "less/before", then
+ * "more/after" — the order the header dropdowns always shipped).
+ */
+export declare const ALLOWED_OPERATORS: {
+    readonly text: readonly [MatchModeCodes.StartsWith, MatchModeCodes.Contains, MatchModeCodes.Equals];
+    readonly number: readonly [MatchModeCodes.Equals, MatchModeCodes.LessThan, MatchModeCodes.GreaterThan, MatchModeCodes.In];
+    readonly boolean: readonly [MatchModeCodes.Equals];
+    readonly date: readonly [MatchModeCodes.Equals, MatchModeCodes.LessThan, MatchModeCodes.GreaterThan];
+};
+export type FilterValueKind = keyof typeof ALLOWED_OPERATORS;
+/** The compile-time half of one kind's row, derived so it can never drift from the runtime half. */
+export type AllowedOperatorFor<TKind extends FilterValueKind> = (typeof ALLOWED_OPERATORS)[TKind][number];

package/lib/filters/filter-store.d.ts

@@ -0,0 +1,264 @@
+import { Signal } from '@angular/core';
+import { FilterRule } from '../entities/filter-rule';
+import { MatchModeCodes } from '../enums/match-mode-enum-codes';
+import { ALLOWED_OPERATORS, AllowedOperatorFor, FilterValueKind } from './allowed-operators';
+/** One tickable choice. `value` is the filter's own value type — an id, not a display string. */
+export interface FilterOption {
+    value: unknown;
+    label: string;
+}
+/**
+ * A filter declaration. It carries its VALUE type, never a UI control name — that separation is
+ * the whole point: `multiselect` is a control, and it emits `In`, which `AllowedMatchModes` allows
+ * on a number and forbids on a string. Conflating the two is what shipped `paymentGatewayCode` as
+ * a text filter with a hand-written comment instead of a compile error.
+ */
+export interface FilterDefinition<TKind extends FilterValueKind = FilterValueKind> {
+    kind: TKind;
+    label: string;
+    /**
+     * Declaring options turns this filter into a pick-list, which means `In` — the same rule as the
+     * table's `[filters]`, where the SHAPE of what is supplied decides, not a mode flag. It is also
+     * the only way "Processing OR PreparingForShipping" can be expressed at all.
+     */
+    options?: FilterOption[];
+    /** Offered-operator narrowing; semantics on `FilterConfig.operators`, the factories' door. */
+    operators?: MatchModeCodes[];
+    /** Whether "+ Filter" offers it; semantics on `FilterConfig.offered`, the factories' door. */
+    offered?: boolean;
+}
+export interface OperatorOption {
+    value: MatchModeCodes;
+    /** Transloco key, resolved by the control — the store holds no translations. */
+    labelKey: string;
+}
+/**
+ * A KIND's operator picker options, for callers with no filter behind them — today that is
+ * `spiderly-data-view`, whose own filter config derives its operator lists here instead of
+ * hand-keeping copies (the drift `allowed-operators.ts` exists to end). Per-FILTER narrowing
+ * lives in the store (`createFilterStore` resolves it once per declaration), so this cannot be
+ * handed a fake definition to satisfy — that shape shipped once and interpolated an empty
+ * filter name into its own error message.
+ */
+export declare function operatorOptionsForKind(kind: FilterValueKind, hasOptions?: boolean): OperatorOption[];
+/**
+ * The operator applied when nobody picked one, which has to be what a person MEANS by filling in
+ * the control. `Contains` for a fragment typed into a box; `GreaterThan` for a date, never
+ * `Equals` — a date equality against a TIMESTAMP matches only the row written in that exact
+ * second, and answers with an empty grid rather than an error (PACMS ran into this on all three
+ * of its date columns, Filip 2026-08-28).
+ */
+export declare const DEFAULT_OPERATOR: {
+    readonly text: MatchModeCodes.Contains;
+    readonly number: MatchModeCodes.Equals;
+    readonly boolean: MatchModeCodes.Equals;
+    readonly date: MatchModeCodes.GreaterThan;
+};
+/** The value each kind carries. Exhaustive over the kinds by construction. */
+interface ValueByKind {
+    text: string;
+    number: number;
+    boolean: boolean;
+    date: Date;
+}
+/**
+ * What every factory takes, so narrowing does not have to be re-plumbed per factory (its adjacent
+ * asymmetry — `options` on `numberFilter` only — is FORCED and documented there; this one is not).
+ *
+ * `operators` narrows what the editor OFFERS, in display order; the first entry becomes the
+ * default. Typed per kind, so declaring an operator the kind cannot answer is a build error at
+ * the declaration — the store's runtime drop-and-report covers only what dodges the type system
+ * (a dynamically built array). The store still accepts every wire-legal operator on restore, so
+ * an old persisted constraint keeps filtering: the narrowing shapes the controls, not the
+ * contract. The forcing case: date-equality against a timestamp matches one second and answers
+ * with an empty grid, so PACMS's order dates offer only "posle"/"pre".
+ */
+interface FilterConfig<TKind extends FilterValueKind> {
+    label: string;
+    operators?: AllowedOperatorFor<TKind>[];
+    /**
+     * `false` keeps the filter out of the bar's "+ Filter" menu — for a filter with a DEDICATED
+     * control somewhere on the page (PACMS's order search box is a placement of the store's
+     * `mixedSearch`), where the generic entry point would give one question two homes. The chip
+     * still renders when the filter is applied, so the bar's claim to list every constraint holds.
+     */
+    offered?: boolean;
+}
+export declare function textFilter(config: FilterConfig<'text'>): FilterDefinition<'text'>;
+/**
+ * Only a NUMBER filter accepts options, and the asymmetry is forced rather than chosen: options
+ * mean `In`, and `In` is the one operator ALLOWED_OPERATORS grants to numbers alone — because the
+ * generated paginator answers it with InvalidMatchMode on a string column. A text pick-list used
+ * to type-check and then throw at the first `set`.
+ */
+export declare function numberFilter(config: FilterConfig<'number'> & {
+    options?: FilterOption[];
+}): FilterDefinition<'number'>;
+export declare function booleanFilter(config: FilterConfig<'boolean'>): FilterDefinition<'boolean'>;
+export declare function dateFilter(config: FilterConfig<'date'>): FilterDefinition<'date'>;
+/**
+ * `In` is the only multi-valued operator MatchModeCodes has, so it is the only one whose value is
+ * a list. Distributing over the operator union yields a discriminated union rather than a loose
+ * `T | T[]`, so `{ operator: Equals, value: [2, 3] }` is a compile error rather than a query the
+ * paginator answers in some way nobody predicted.
+ */
+type ConstraintFor<TKind extends FilterValueKind, TOperator> = TOperator extends MatchModeCodes.In ? {
+    operator: TOperator;
+    value: ValueByKind[TKind][] | null | undefined;
+} : {
+    operator: TOperator;
+    value: ValueByKind[TKind] | null | undefined;
+};
+/**
+ * The kind is what carries BOTH halves — which operators are legal and what the value is. It has
+ * to stay a literal all the way from the factory to here: typing the definition's `kind` as the
+ * widened `FilterValueKind` silently allows every operator on every filter, which is the shape
+ * this first had (the runtime guard still fired, so only a `@ts-expect-error` pin caught it).
+ */
+export type FilterConstraint<TKind extends FilterValueKind> = ConstraintFor<TKind, (typeof ALLOWED_OPERATORS)[TKind][number]>;
+/** One filter, addressed on its own. The placement API, and what the bar's editor drives. */
+export interface FilterHandle {
+    id: string;
+    label: string;
+    kind: FilterValueKind;
+    /** The DRAFT — what a control shows. `applied()` answers the other question. */
+    value: Signal<unknown>;
+    operator: Signal<MatchModeCodes | undefined>;
+    /** Every operator this filter accepts, in display order. */
+    operators: OperatorOption[];
+    /** Applied when nobody picked an operator. */
+    defaultOperator: MatchModeCodes;
+    /** The tickable choices, when this filter declares any. */
+    options?: FilterOption[];
+    set(constraint: {
+        operator: MatchModeCodes;
+        value: unknown;
+    }): void;
+    commit(): void;
+    reset(): void;
+}
+/**
+ * What the CHIP BAR needs from a store, and no more: it reads the applied set and removes from it.
+ * Narrow on purpose — it keeps the bar free of the store's generics, so the bar renders any store
+ * without the two types having to agree on filter ids.
+ */
+export interface FilterBarSource {
+    /** Every DECLARED filter, which is what "+ Filter" offers — not every visible column. */
+    definitions: Record<string, FilterDefinition<FilterValueKind>>;
+    applied: Signal<AppliedFilter[]>;
+    get(id: string): FilterHandle;
+    reset(id: string): void;
+    clear(): void;
+}
+/** What the TABLE needs: the bar's half, plus the payload it sends to the paginator. */
+export interface FilterSource extends FilterBarSource {
+    toFilterPayload(): Record<string, FilterRule[]>;
+    /** The applied set as plain JSON, for whoever owns this table's persisted state. */
+    snapshot(): FilterSnapshot;
+    /** Replaces the applied set, and the drafts with it so every control agrees with its chip. */
+    restore(snapshot: FilterSnapshot): void;
+}
+/** The applied constraints in a form that survives `JSON.stringify`. */
+export type FilterSnapshot = Record<string, {
+    operator: MatchModeCodes;
+    value: unknown;
+}>;
+/**
+ * One sort key as the bar draws it. Sort deliberately does NOT live in the filter store:
+ * `multiSortMeta` already holds it, keyed by field, and a copy here would be a second source of
+ * truth for one fact. The bar is one surface reading two owners.
+ */
+export interface SortKeyLabel {
+    label: string;
+    descending: boolean;
+}
+/** One applied constraint, in the shape the chip bar draws. */
+export interface AppliedFilter {
+    id: string;
+    label: string;
+    /** The bar reads this to word the chip — `String(false)` would print "false" at an operator. */
+    kind: FilterValueKind;
+    operator: MatchModeCodes;
+    /**
+     * Transloco key for the chip's middle word. Without it a chip reads "Firma Elektromont", which
+     * leaves the reader to guess whether the grid is narrowed by `contains` or by `equals` — very
+     * different sets for one typed value, on a surface whose only claim is that it cannot lie.
+     */
+    operatorPhraseKey: string;
+    value: unknown;
+}
+/**
+ * The filter engine. It knows nothing about columns: a filter has an id, a value type and a
+ * constraint, and that is the entire vocabulary.
+ */
+export declare function createFilterStore<TDefs extends Record<string, FilterDefinition<FilterValueKind>>>(definitions: TDefs): {
+    definitions: TDefs;
+    applied: Signal<AppliedFilter[]>;
+    /**
+     * A handle bound to one filter. This is the PLACEMENT api: it needs nothing from the component
+     * tree, so the same filter can be driven from the bar, from a header cell, or from a drawer
+     * rendered at app root. `value` is the DRAFT — a control shows what was typed, not what was
+     * applied; `applied()` is the other question and the bar asks that one.
+     */
+    get<K extends keyof TDefs>(id: K): {
+        id: string;
+        label: string;
+        kind: "number" | "boolean" | "text" | "date";
+        value: Signal<unknown>;
+        operator: Signal<MatchModeCodes>;
+        readonly operators: OperatorOption[];
+        readonly defaultOperator: MatchModeCodes;
+        readonly options: FilterOption[];
+        set: (constraint: FilterConstraint<TDefs[K]["kind"]>) => void;
+        commit: () => void;
+        reset: () => void;
+    };
+    /**
+     * The ONE seam for choices that arrive after the store is built (PACMS fills its pick-lists
+     * from lookups that race a deploy). Never write `definitions[id].options` by hand: options'
+     * PRESENCE is what makes a filter a pick-list, so the setter also re-resolves the offered
+     * operators — a hand write would leave a late-filled filter offering `Equals` on a control
+     * that emits a list.
+     */
+    setOptions<K extends keyof TDefs>(id: K, options: FilterOption[]): void;
+    set<K extends keyof TDefs>(id: K, constraint: FilterConstraint<TDefs[K]["kind"]>): void;
+    /**
+     * `set` + `commit` in one breath — the shape every PROGRAMMATIC write takes (a view's
+     * `apply`, the sheet flow). The split API stays for controls, where draft-on-type /
+     * publish-on-Apply is the point; but a bare `set` whose `commit` is forgotten (or written
+     * with the wrong id — the pair repeats the string twice) fails silently: the draft is
+     * written, nothing is published, and a view narrows by nothing under a labelled tab.
+     */
+    setAndCommit<K extends keyof TDefs>(id: K, constraint: FilterConstraint<TDefs[K]["kind"]>): void;
+    /**
+     * Publishes the draft. A blanked draft REMOVES the constraint rather than committing an empty
+     * one, so `applied()` and the payload agree: no chip, no key, no `contains ''`.
+     */
+    commit<K extends keyof TDefs>(id: K): void;
+    /**
+     * The chip's `x`. Drops the DRAFT as well as the committed constraint: a surviving draft
+     * leaves the control still showing the cleared text, and the next commit would restore a
+     * filter nobody re-typed.
+     */
+    reset<K extends keyof TDefs>(id: K): void;
+    /**
+     * The applied set, plain enough to store. Drafts are deliberately NOT included: a half-typed
+     * value is not a state anyone should come back to, and the bar's whole claim is that what it
+     * shows is what narrows the grid.
+     */
+    snapshot(): FilterSnapshot;
+    /**
+     * Replaces the applied set. The drafts are written too, so reopening a restored chip shows
+     * the value it is filtering by rather than an empty control.
+     *
+     * Ids the store no longer declares are dropped rather than carried: a filter removed from the
+     * declaration in a later release would otherwise ride every request from anyone whose storage
+     * still held it, with no chip able to name it and no way to clear it from the UI.
+     */
+    restore(snapshot: FilterSnapshot): void;
+    /** The bar's "Clear all". `reset` for every filter, drafts included. */
+    clear(): void;
+    /** The `filters` half of `Filter` — what the generated paginator reads. */
+    toFilterPayload(): Record<string, FilterRule[]>;
+};
+export {};

package/lib/filters/spiderly-filter-bar.component.d.ts

@@ -0,0 +1,132 @@
+import { QueryList, TemplateRef } from '@angular/core';
+import { SpiderlyFilterTemplateDirective } from '../directives/spiderly-filter-template.directive';
+import { MatchModeCodes } from '../enums/match-mode-enum-codes';
+import { AppliedFilter, FilterBarSource, FilterHandle, FilterOption, SortKeyLabel } from './filter-store';
+import * as i0 from "@angular/core";
+/**
+ * Lowercased and stripped of diacritics for matching. NFD decomposition handles č/ć/š/ž, but NOT
+ * đ — it is its own letter (U+0111), not a d carrying a mark, so it decomposes to nothing and has
+ * to be mapped by hand.
+ *
+ * It maps to "dj", which is what the rest of this workspace already does (pa-cms's
+ * `normalizePlaceQuery` and `toAscii`, the backend's `PlaceNameNormalizer`) and what someone
+ * without a Serbian layout actually types. Mapping it to "d" — as this first shipped — folds
+ * "Đorđe" to "dorde", so typing "djordje" finds nothing: the exact case the comment claimed to
+ * fix, and one no spec covered because the test used "drzava", which has no đ in it.
+ */
+export declare function foldForSearch(value: string): string;
+/**
+ * The visible home of every applied constraint. This is what licenses a hidden column keeping its
+ * filter: the header is no longer the only place a filter can be seen, so hiding a column stops
+ * meaning "silently drop what it was filtering by".
+ *
+ * Everything drawn here comes from `applied()`, never from a draft — a chip over a half-typed
+ * value would repeat the mistake the header's filter icon shipped, claiming the grid is narrowed
+ * while it still shows every row.
+ */
+export declare class SpiderlyFilterBarComponent {
+    readonly filters: import("@angular/core").InputSignal<FilterBarSource>;
+    /** The current query's row count, supplied by whoever owns the query. Null hides the counter. */
+    readonly totalRecords: import("@angular/core").InputSignal<number>;
+    /**
+     * What the grid is ordered by, in priority order and already LABELLED — the bar knows nothing
+     * about columns, so whoever owns the sort resolves the names.
+     */
+    readonly sort: import("@angular/core").InputSignal<SortKeyLabel[]>;
+    /** Asked for, never done here — see the button's comment. */
+    readonly clearAll: import("@angular/core").OutputEmitterRef<void>;
+    private readonly transloco;
+    /** For the chip's date wording — the same locale mechanism the table's cells format with. */
+    private readonly locale;
+    /**
+     * Controls a consumer projected for specific filters, collected by whoever hosts this bar. A
+     * filter with no template keeps the control the bar draws for its kind, so a table opts in one
+     * filter at a time.
+     */
+    readonly controlTemplates: import("@angular/core").InputSignal<QueryList<SpiderlyFilterTemplateDirective>>;
+    readonly isAddOpen: import("@angular/core").WritableSignal<boolean>;
+    /** Cleared when the popover closes, so reopening never starts inside someone's old query. */
+    readonly addSearch: import("@angular/core").WritableSignal<string>;
+    /** The filter whose control is open. One at a time: the bar edits, it is not a form. */
+    readonly editing: import("@angular/core").WritableSignal<FilterHandle>;
+    /**
+     * `addable` narrowed by the search box. Matching is unaccented and case-folded because that is
+     * how the label gets typed: "drzava" for "Država" on any keyboard without a Serbian layout. The
+     * backend's own product search is unaccented for the same reason.
+     */
+    readonly offered: import("@angular/core").Signal<{
+        kind: "number" | "boolean" | "text" | "date";
+        label: string;
+        options?: FilterOption[];
+        operators?: MatchModeCodes[];
+        offered?: boolean;
+        id: string;
+    }[]>;
+    /**
+     * What "+ Filter" offers: every declared filter that is not already on the bar. Sourced from the
+     * DEFINITIONS, so a filter reaches this list whether or not it has a column, and whether or not
+     * that column is visible. That is the whole reason the bar exists.
+     *
+     * `offered: false` filters stay out — they have a dedicated control of their own on the page
+     * (PACMS's order search box), so the generic entry point would give one question two homes.
+     * Their chips still render: the applied list above reads no such flag.
+     */
+    readonly addable: import("@angular/core").Signal<{
+        kind: "number" | "boolean" | "text" | "date";
+        label: string;
+        options?: FilterOption[];
+        operators?: MatchModeCodes[];
+        offered?: boolean;
+        id: string;
+    }[]>;
+    /** Opens a filter's control. Where it renders, and why not a popover: the template comment. */
+    startEditing(id: string): void;
+    /** The raw-string controls only. Nothing reaches the bar or the query until `apply`. */
+    draft(handle: FilterHandle, event: Event): void;
+    controlTemplateFor(handle: FilterHandle): TemplateRef<unknown> | null;
+    /**
+     * The open editor's operator options, already translated — p-select takes labels, not keys.
+     *
+     * A `computed`, not a method in the binding: both inputs are fixed for the life of an open
+     * editor, and PrimeNG's `Select.options` setter deep-compares whatever it is handed — so a
+     * freshly mapped array per change-detection pass paid for a recursive structural compare to
+     * conclude nothing had changed.
+     */
+    readonly operatorChoices: import("@angular/core").Signal<{
+        label: string;
+        value: MatchModeCodes;
+    }[]>;
+    /**
+     * The ONE write path, whatever the control. Every PrimeNG control here hands back a value of
+     * the right type already — a Date from the datepicker, a boolean from the checkbox, the whole
+     * array from the multiselect — so only the raw string ones need coercing, and only they go
+     * through `draft`.
+     */
+    draftValue(handle: FilterHandle, value: unknown): void;
+    /**
+     * Changing the direction re-commits nothing on its own — it rewrites the draft, so the operator
+     * survives until Apply like the value does.
+     */
+    pickOperator(handle: FilterHandle, operator: MatchModeCodes): void;
+    /**
+     * A DOM control hands back a string; the store holds the value type the filter declared.
+     *
+     * The empty case is the trap and it is not symmetric: `Number('')` is 0, so an emptied number
+     * box would apply a filter for zero and draw a chip over a control the operator had just
+     * cleared. `NaN` is folded in for the same reason — the store's `isBlank` cannot recognise
+     * either of them as "nothing was entered", because by then they are perfectly good numbers.
+     */
+    private coerce;
+    apply(handle: FilterHandle): void;
+    /**
+     * `In` is the multi-valued operator, so its chip reads as a list — in the OPTIONS' words, not
+     * the wire's: "Status is one of 2, 3" narrates ids nobody chose by number. The lookup is live
+     * off the definition rather than snapshotted at commit, because option lists can be filled
+     * asynchronously (PACMS's admin/backend deploy race): a chip restored before the lookup answers
+     * upgrades from ids to labels the moment the options land, and a failed lookup degrades to the
+     * honest raw value.
+     */
+    chipValue(chip: AppliedFilter): string;
+    static ɵfac: i0.ɵɵFactoryDeclaration<SpiderlyFilterBarComponent, never>;
+    static ɵcmp: i0.ɵɵComponentDeclaration<SpiderlyFilterBarComponent, "spiderly-filter-bar", never, { "filters": { "alias": "filters"; "required": true; "isSignal": true; }; "totalRecords": { "alias": "totalRecords"; "required": false; "isSignal": true; }; "sort": { "alias": "sort"; "required": false; "isSignal": true; }; "controlTemplates": { "alias": "controlTemplates"; "required": false; "isSignal": true; }; }, { "clearAll": "clearAll"; }, never, never, true, never>;
+}

package/lib/services/helper-functions.d.ts

@@ -6,6 +6,7 @@ import { SpiderlyTab } from '../components/spiderly-panels/panel-header/panel-he
 import { Codebook } from '../entities/codebook';
 import { Filter } from '../entities/filter';
 import { Namebook } from '../entities/namebook';
+import { FilterOption } from '../filters/filter-store';
 import { PrimengOption } from '../entities/primeng-option';
 export declare function validatePrecisionScale(value: any, precision: number, scale: number, ignoreTrailingZeros: boolean): boolean;
 export declare function getMimeTypeForFileName(fileName: string): string;
@@ -29,6 +30,13 @@ export declare function isExcelFileType(mimeType: string): boolean;
 export declare function saveResponseAsFile(res: HttpResponse<Blob>, fallbackName: string): void;
 export declare function exportListToExcel(exportListToExcelObservableMethod: (filter: Filter) => Observable<any>, filter: Filter): void;
 export declare function getPrimengNamebookOptions(namebookList: Namebook[]): PrimengOption[];
+/**
+ * The filter store's twin of `getPrimengNamebookOptions` — same namebook in, the store's
+ * `{ value, label }` shape out (a `FilterOption` is not a `PrimengOption`: that one's `code` is
+ * deliberate, see `primeng-option.ts`). Every consumer filling a pick-list filter from a lookup
+ * needs this map; without it each page re-derives the three lines.
+ */
+export declare function getFilterOptions(namebookList: Namebook[]): FilterOption[];
 export declare function getPrimengDropdownNamebookOptions(getDropdownListObservable: (parentEntityId?: number) => Observable<Namebook[]>, parentEntityId?: number): Observable<PrimengOption[]>;
 export declare function getPrimengDropdownCodebookOptions(getDropdownListObservable: () => Observable<Codebook[]>): Observable<PrimengOption[]>;
 export declare function getPrimengAutocompleteNamebookOptions(getAutocompleteListObservable: (limit: number, query: string, parentEntityId?: number) => Observable<Namebook[]>, limit: number, query: string, parentEntityId?: number): Observable<PrimengOption[]>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spiderly",
-  "version": "19.11.9",
+  "version": "19.12.1",
   "author": "Filip Trivan",
   "license": "MIT",
   "description": "Spiderly Angular Library to use in combination with Spiderly.",

package/public-api.d.ts

@@ -41,6 +41,11 @@ export * from './lib/components/spiderly-buttons/spiderly-button-base/spiderly-b
 export * from './lib/components/spiderly-buttons/spiderly-button/spiderly-button.component';
 export * from './lib/components/spiderly-buttons/spiderly-split-button/spiderly-split-button.component';
 export * from './lib/components/spiderly-data-table/spiderly-data-table.component';
+export * from './lib/directives/spiderly-filter-template.directive';
+export * from './lib/directives/spiderly-overflow-title.directive';
+export * from './lib/filters/allowed-operators';
+export * from './lib/filters/filter-store';
+export * from './lib/filters/spiderly-filter-bar.component';
 export * from './lib/components/spiderly-data-view/spiderly-data-view.component';
 export * from './lib/components/spiderly-delete-dialog/spiderly-delete-confirmation.component';
 export * from './lib/components/spiderly-form-control/spiderly-form-control';