spiderly 19.12.0 → 19.12.2

package/lib/components/spiderly-data-table/spiderly-data-table.component.d.ts

@@ -1,4 +1,4 @@
-import { AfterViewInit, ErrorHandler, EventEmitter, OnChanges, OnDestroy, OnInit, QueryList, TemplateRef } from '@angular/core';
+import { AfterViewInit, ErrorHandler, EventEmitter, OnChanges, OnDestroy, OnInit, QueryList, SimpleChanges, TemplateRef } from '@angular/core';
 import { ActivatedRoute, Router } from '@angular/router';
 import { TranslocoService } from '@jsverse/transloco';
 import { SortMeta } from 'primeng/api';
@@ -10,7 +10,7 @@ import { Filter } from '../../entities/filter';
 import { LazyLoadSelectedIdsResult } from '../../entities/lazy-load-selected-ids-result';
 import { PaginatedResult } from '../../entities/paginated-result';
 import { PrimengOption } from '../../entities/primeng-option';
-import { FilterSource, SortKeyLabel } from '../../filters/filter-store';
+import { FilterSource, SortKeyLabel, SortPickOption } from '../../filters/filter-store';
 import { SpiderlyFilterTemplateDirective } from '../../directives/spiderly-filter-template.directive';
 import { ConfigServiceBase } from '../../services/config.service.base';
 import { SpiderlyMessageService } from '../../services/spiderly-message.service';
@@ -106,7 +106,8 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
     /** Saved questions for this table, rendered as tabs above the bar. */
     views?: TableView[];
     /**
-     * The view currently selected. Seeded from the first view in `ngOnInit`, never left null on a
+     * The view currently selected. Seeded from the first view in `ngOnInit` — then overridden by
+     * `restoreActiveView`, so a reload lands where the operator was — and never left null on a
      * table that has views: `viewScope` keys the layout off it, so an unseeded table writes its
      * width and order to the SAME key an unmigrated table uses — orphaned the moment the operator
      * clicks the first tab — and no tab reads as selected until they do.
@@ -229,7 +230,7 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      * backend `.Take`s whatever it is sent.
      */
     private mergeActivePageSizesIntoOptions;
-    ngOnChanges(): void;
+    ngOnChanges(changes: SimpleChanges): void;
     ngOnInit(): void;
     /**
      * User visibility choices (field → visible), holding only fields the user explicitly
@@ -297,11 +298,21 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      * wrap, order and width alike. It undid visibility only until the header menu shipped three
      * more gestures beside it, and a layout with no way back is worse than one with no knobs.
      *
-     * Hiding — here or from the menu — never touches filters or sort: the chip bar names every
-     * applied filter and the sort chip names the sort, hidden column or not (decision 2b). The
-     * legacy "hidden contributes nothing" apparatus died with the header-filter path.
+     * On a STORE table, hiding — here or from the menu — never touches filters or sort: the chip
+     * bar names every applied filter and the sort chip names the sort, hidden column or not
+     * (decision 2b). A storeless table keeps the sort half of the legacy invariant instead — see
+     * `dropHiddenColumnSort`.
      */
     resetColumnLayout(): void;
+    /**
+     * The sort half of the legacy "hidden contributes nothing" invariant, kept ONLY for storeless
+     * tables (the generated M2M details grids, until spiderly#407 scaffolds their stores): they
+     * have no sort chip, so a hidden column's sort would order the grid with nothing on screen
+     * naming it and no control left to clear it. The filter half needs no heir — `lazyLoad`
+     * overwrites the outgoing filters unconditionally. On a store table this is a no-op:
+     * decision 2b's chips are the visible surface, hidden column or not.
+     */
+    private dropHiddenColumnSort;
     /**
      * Per-column wrap, by `field`. A SEPARATE key from the visibility overrides on purpose: folding
      * both into one object would invalidate every layout already in an operator's localStorage, and
@@ -336,8 +347,51 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      */
     private get filtersStateKey();
     private get filterStorage();
+    /**
+     * Where the active view id lives. Deliberately NOT view-scoped — it is the input `viewScope`
+     * derives from — and it follows `stateStorage` like the filters rather than the layout's
+     * always-local rule, because the id and the filters it scopes are one question: a durable id
+     * over session-scoped filters would restore a tab with nothing under it.
+     */
+    private get viewStateKey();
+    /** Only `selectView` writes; the `ngOnInit` seed does not — absence means "the default". */
+    private persistActiveView;
+    /**
+     * Puts a reload back on the view the operator was using. Every persisted key carries the view
+     * segment, so before this existed the seed decided what got restored: F5 landed on the first
+     * view and read `…:all:filters` — the tab snapped to "Sve" and the bar came back empty while
+     * the operator's filters sat intact under the old view's segment (Filip, on /porudzbine).
+     *
+     * An id naming no current view keeps the seed AND the stored key: "vanished by deploy" and
+     * "not yet arrived" are indistinguishable here (order-list's catalog-licensed "Za pakovanje"
+     * is literally both), so `adoptStoredView` re-reads the key on every `[views]` change and the
+     * key self-heals on the next explicit click.
+     */
+    private restoreActiveView;
+    /**
+     * The second half of `restoreActiveView`: a stored view that did not exist at init is adopted
+     * when a later `[views]` change brings it — through `selectView`, so it gets the same
+     * stored-wins/transient/layout/requery semantics a click would have had. There is no parked
+     * copy of the stored id — the key itself is re-read, and because every explicit pick
+     * overwrites it, the operator's own choice wins by construction. Accepted cost of adopting
+     * late instead of holding the first request: a brief flash of the seeded view's rows and a
+     * second request when the late view lands.
+     */
+    private adoptStoredView;
+    private viewById;
     private persistAppliedFilters;
-    private restoreAppliedFilters;
+    /**
+     * Applies the right filters for entering `view` — the transient rule's one home. A TRANSIENT
+     * view's `apply` is a function of NOW, so it always re-derives; restoring would put
+     * yesterday's date under a tab claiming "today" (`persistAppliedFilters` has no transient
+     * guard, so storage holds the LAST answer). A non-transient view's own stored answer wins
+     * over its `apply`. The semantics argument is the one deliberate difference between the
+     * callers: a 'click' re-asks the view's question when nothing is stored, a 'refresh' returns
+     * the empty state the operator left — they cleared it, and F5 must give the cleared state
+     * back. On a table with no views, `view` is null and this is a plain restore of the
+     * `persistAppliedFilters` snapshot.
+     */
+    private enterViewFilters;
     private get layoutStateKey();
     /** One key for the whole layout — wrap now, widths next (decision 5). */
     private persistColumnLayout;
@@ -349,13 +403,83 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      * because we need it before PrimeNG's restoreState() runs on the first [value] change.
      */
     private persistedTableState;
-    /**
-     * The declared default as PrimeNG sort meta, or null when none is declared. Applies even
-     * while its column is hidden: the sort chip names the ordering whether or not the column
-     * is on screen (decision 2b).
+    private activeView;
+    /**
+     * Where the operator's per-view sort override lives. Null on a table without views — those
+     * keep the pure PrimeNG sort persistence they always had — and null on a STORELESS table:
+     * there "hidden contributes nothing" retires a hidden column's sort (`dropHiddenColumnSort`)
+     * with no persist call at the hide site, so an override restored blind at the next init
+     * would re-impose a sort no chip can name. Store tables — where every viewed consumer
+     * lives — have the chip. Follows `stateStorage` like the filters and the view id: the sort
+     * is part of the same question they scope.
+     */
+    private get viewSortStateKey();
+    /** The operator's stored sort for the active view, sanitized like any persisted sort. */
+    private persistedViewSort;
+    /**
+     * THE resolution ladder, named once: the operator's stored override, else the declared
+     * default (`defaultMultiSortMeta` = view's declared sort ?? table default). Null means
+     * "unsorted" — callers append their own `?? []` / blob terms rather than re-spelling the
+     * ladder, so a future term (a per-view default refinement, decision 10's columns half)
+     * lands everywhere at once.
+     */
+    private resolvedViewSort;
+    /**
+     * Records the current sort as the active view's override — called from the EXPLICIT sort
+     * gestures only (header click, `applySort` — the menu and both bar entry points), never
+     * from a load: a sort merely inherited at init must not crystallize into an override, or a
+     * later change to the view's declared sort would stop flowing to operators who never
+     * touched sort — the same flows-through rule `columnVisibilityOverrides` documents. A sort
+     * equal to the declared default is stored as ABSENCE for the same reason.
+     */
+    private persistActiveViewSort;
+    /**
+     * Puts the entering view's sort on the grid — stored override, else declared sort, else the
+     * table default, else UNSORTED. A view is a COMPLETE state, sort included (2026-09-06,
+     * grilled — supersedes the "a view stating no preference keeps the ordering already there"
+     * this first shipped with): the carried-over ordering read as a bug in its first live week,
+     * when "Poslate"'s statusChangedAt rode onto "Sve", whose sorted column ships hidden —
+     * read-only chip, no header to tri-state, no way out. Polaris IndexFilters is the model:
+     * sort is part of a view's saved definition. Broadcast only — the caller owns the refetch,
+     * because which request carries the new sort differs between the store and storeless paths.
+     */
+    private applyViewSort;
+    /**
+     * Rewrites the sort inside PrimeNG's persisted state to the one `ngOnInit` resolved. The two
+     * can disagree only on a viewed table — PrimeNG's state is table-global while the resolved
+     * sort is the view's — and PrimeNG's restoreState() applies its copy on the first [value]
+     * change, AFTER the initial request already left with ours: without this line the grid's
+     * arrows and every later request silently fall back to the other view's sort. Handed the
+     * already-parsed state: `ngOnInit` reads the blob once for the whole init pass.
+     */
+    private alignPersistedTableStateSort;
+    /**
+     * The DECLARED default in the current context: the active view's own sort when it declares
+     * one, else the table-level `defaultSortField`. Every "fall back to the declared default"
+     * site — tri-state un-sort, Clear filters, the unsorted-load safety net — reads this, so
+     * un-sorting inside a view lands on the view's ordering, not the table's.
      */
     private defaultMultiSortMeta;
-    private persistedMultiSortMeta;
+    /**
+     * The active view's declared sort, sanitized: a non-sortable field would answer every load
+     * with a 400 (`keepSortableMeta`'s rationale), so it is dropped rather than sent; a view
+     * whose declaration sanitizes to nothing falls through to the table default.
+     */
+    private viewDeclaredMultiSortMeta;
+    /**
+     * The table-level declared default as PrimeNG sort meta, or null when none is declared. On a
+     * store table it applies even while its column is hidden — the sort chip names the ordering
+     * whether or not the column is on screen (decision 2b). A STORELESS table has no chip, so a
+     * hidden default would order the grid with nothing on screen naming it; there the default
+     * dies with the column, exactly as the legacy invariant had it (see `dropHiddenColumnSort`).
+     */
+    private tableDefaultMultiSortMeta;
+    /**
+     * `keepSortableMeta` with "sanitized to nothing" surfaced as null — the rule every sort
+     * SOURCE shares ("a sort that sanitizes to nothing is no sort"), so the resolution chains
+     * can `??` past an empty answer instead of stopping on an empty array.
+     */
+    private sanitizedSortMeta;
     /**
      * Drops sort meta the backend has no sort case for. Persisted state outlives the rule that
      * produced it — a sort stored before a column became non-sortable (or before the library
@@ -367,6 +491,8 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      */
     private keepSortableMeta;
     private applyDefaultSortIfUnsorted;
+    /** Puts `meta` on the grid and tells the header icons — no fetch; the caller owns that. */
+    private broadcastSort;
     onPageChange(container: HTMLElement): void;
     /**
      * The one pending predicate: PrimeNG's overlay and the container's `aria-busy` must never
@@ -421,8 +547,8 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
     /**
      * Switches to a view. Clears first, always: a view is a STATE rather than an addition, and two
      * of them composed produce a question nobody asked. The clear runs through the store directly
-     * rather than through `clear(table)`, which would also wipe the sort and the persisted state a
-     * view is entitled to keep.
+     * rather than through `clear()`, whose requery effect would spend a fetch before the entering
+     * view's filters are in place.
      */
     selectView(view: TableView): void;
     /**
@@ -519,6 +645,35 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      * left falls back to its own name rather than vanishing.
      */
     private refreshSortKeys;
+    /**
+     * Gates the picker's reset row. Refreshed with `sortKeys` — same request, same reason it is a
+     * field rather than a getter. "Default" is view-aware (`defaultMultiSortMeta`), so inside a
+     * view the row offers the view's ordering back, not the table's.
+     */
+    sortIsDefault: boolean;
+    /**
+     * What the bar's picker offers: every sortable data column, hidden ones INCLUDED — the picker
+     * exists so an ordering does not need its column on screen. Built once in `ngOnInit` (columns
+     * are a declaration, not state) and labelled here because the bar knows nothing about columns.
+     */
+    sortPickOptions: SortPickOption[];
+    /**
+     * The one body of an explicit sort GESTURE — the thing `persistActiveViewSort`'s doc calls
+     * "explicit gestures only": page one, meta on the grid, fetch, save, selection anchor
+     * invalidated, override recorded. Shared by the header's single-click un-sort, the header
+     * menu and both bar entry points; `broadcastSort` is its deliberate no-fetch sibling. The
+     * page reset, `saveState` and anchor line mirror PrimeNG's own `sort()` (`sortMultiple()`
+     * does none of the three); the "lands on page one" / "survives a reload" specs pin why.
+     */
+    private applySort;
+    /** The picker's ask: one sort, replacing the whole meta — the same contract as the header menu. */
+    sortFromBar(pick: SortMeta): void;
+    /**
+     * Back to the resolved default — the view's declared sort, else the table default, else
+     * unsorted. Persisting right after is what empties the override slot: a sort equal to the
+     * default is stored as absence, so the declared ordering flows through again.
+     */
+    resetSortFromBar(): void;
     /** This column's share, override first, then its declared width, then the per-type default. */
     columnShare(col: Column): number;
     /**
@@ -579,6 +734,15 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
      * make every table load twice.
      */
     private requeryOnAppliedFilters;
+    /**
+     * Back to page one, state saved, one fetch off FRESH metadata — the shared tail of the
+     * requery effect and `selectView`'s sort-only switch. The save is load-bearing: PrimeNG
+     * saves state only from its own interactions, so without it the pre-change page offset
+     * survives in storage and the NEXT visit replays it against a narrowed result set — the
+     * backend answers data=[] for an offset the filtered total no longer reaches, and the grid
+     * renders empty under chips claiming matches.
+     */
+    private refetchFromFirstPage;
     reload(): void;
     showActions(): boolean;
     getStyleForBodyColumn(col: Column<any>): string;
@@ -590,11 +754,16 @@ export declare class SpiderlyDataTableComponent implements OnInit, OnChanges, Af
     actionTrackByFn(index: any, item: Action): string;
     exportListToExcel(): void;
     /**
-     * Clears everything that narrows the grid. With a store supplied it has to reach BOTH — the
-     * store holds the constraints and PrimeNG holds the persisted state and sort — or the bar goes
-     * empty while a reload brings the old filters back.
+     * Clears the FILTERS — and nothing else (2026-09-06, grilled). It used to also reach the
+     * sort and PrimeNG's persisted state, which made "Clear filters" a reset the label never
+     * claimed: sort is its own channel with its own affordances (the bar's picker, the header's
+     * tri-state), mirroring Polaris, where onClearAll is wired to the Filters while
+     * sortSelected never passes through it. The store's requery effect owns the refetch and the
+     * persisted-snapshot update — the button only renders with chips on the bar, so the applied
+     * set always changes — and dropping table.clear() also drops the second, unsequenced
+     * request the 2026-09-05 review flagged on every Clear.
      */
-    clear(table: Table): void;
+    clear(): void;
     setFakeIsAllSelected(): void;
     selectAll(checked: boolean): void;
     /**
@@ -677,6 +846,15 @@ export interface TableView<TFilters = any> {
      * transience is about the QUESTION, not the furniture.
      */
     transient?: boolean;
+    /**
+     * The view's declared ordering — for the view whose question includes one ("oldest shipped
+     * first" IS the work list, not a reading preference). Entering the view applies it; the
+     * tri-state un-sort and Clear filters return to it instead of the table default; an operator's
+     * own sort overrides it, persisted per view on store tables (decision 10's sort half). A view
+     * declaring none keeps whatever ordering the grid already has, exactly as before this field
+     * existed.
+     */
+    sort?: SortMeta[];
 }
 export declare class Column<T = any> {
     name?: string;
@@ -703,9 +881,17 @@ export declare class Column<T = any> {
      * only so details-table cols emitted by an OLDER Spiderly.SourceGenerators (which wrote
      * `showMatchModes: true`) still compile against this library during a mixed-version window —
      * a consumer on published NuGet generators plus an npm-linked library build. Delete it once
-     * every consumer regenerates with a generator from this release or later.
+     * every consumer regenerates with a generator from this release or later (spiderly#407).
      */
     showMatchModes?: boolean;
+    /**
+     * @deprecated The same version-skew bridge as {@link showMatchModes}, and nothing else: older
+     * generators emit `filterField: 'xxxId'` for every dropdown-typed details-table column, so
+     * deleting it breaks the mixed window the moment a consumer adds one. NOTHING reads it —
+     * filter ids live in the store, linked from a column via {@link filterId}. Delete with
+     * `showMatchModes` (spiderly#407).
+     */
+    filterField?: string & keyof T;
     dropdownOrMultiselectValues?: PrimengOption[];
     actions?: Action[];
     editable?: boolean;
@@ -742,12 +928,13 @@ export declare class Column<T = any> {
      * Not applied to editable cells — those belong to their inline input.
      */
     onCellClick?: (event: CellClickEvent) => void;
-    constructor({ name, field, filterType, filterId, showMatchModes, dropdownOrMultiselectValues, actions, editable, showTime, decimalPlaces, sortable, visible, lockVisible, width, onCellClick, }?: {
+    constructor({ name, field, filterType, filterId, showMatchModes, filterField, dropdownOrMultiselectValues, actions, editable, showTime, decimalPlaces, sortable, visible, lockVisible, width, onCellClick, }?: {
         name?: string;
         field?: string & keyof T;
         filterType?: 'text' | 'date' | 'multiselect' | 'boolean' | 'numeric' | 'blob';
         filterId?: string;
         showMatchModes?: boolean;
+        filterField?: string & keyof T;
         dropdownOrMultiselectValues?: PrimengOption[];
         actions?: Action[];
         editable?: boolean;

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

@@ -4,10 +4,11 @@ import { MatchModeCodes } from '../enums/match-mode-enum-codes';
  * 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 both consumers can derive from
- * it without a cycle: the store's runtime validation and offered lists (`filter-store.ts`), and
- * the compile-time `FilterRule.matchMode` union (`entities/filter-rule.ts`). These used to be
- * hand-kept copies; edit the table here and every surface follows.
+ * 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).

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

@@ -32,6 +32,15 @@ export interface OperatorOption {
     /** 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
@@ -155,12 +164,22 @@ export type FilterSnapshot = Record<string, {
     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.
+ * One column the bar's sort picker offers, labelled by whoever owns the columns — the bar knows
+ * nothing about them. Hidden sortable columns belong in the list: the picker exists precisely so
+ * an ordering does not need its column on screen (decision 2b's sort half).
  */
-export interface SortKeyLabel {
+export interface SortPickOption {
+    field: string;
     label: string;
+}
+/**
+ * One sort key as the bar draws it — a pick option WITH its direction. 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. `field` is what lets the picker mark the active row and flip its direction; the
+ * label alone could not say which option it names once two columns share a name.
+ */
+export interface SortKeyLabel extends SortPickOption {
     descending: boolean;
 }
 /** One applied constraint, in the shape the chip bar draws. */

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

@@ -1,7 +1,8 @@
 import { QueryList, TemplateRef } from '@angular/core';
+import { SortMeta } from 'primeng/api';
 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 { AppliedFilter, FilterBarSource, FilterHandle, FilterOption, SortKeyLabel, SortPickOption } from './filter-store';
 import * as i0 from "@angular/core";
 /**
  * Lowercased and stripped of diacritics for matching. NFD decomposition handles č/ć/š/ž, but NOT
@@ -33,8 +34,20 @@ export declare class SpiderlyFilterBarComponent {
      * about columns, so whoever owns the sort resolves the names.
      */
     readonly sort: import("@angular/core").InputSignal<SortKeyLabel[]>;
+    /**
+     * What the picker offers, labelled by the owner — every sortable column, HIDDEN ones
+     * included (their ordering is otherwise unreachable, which is the trap the picker closes).
+     * Empty keeps the chip read-only and the picker off.
+     */
+    readonly sortOptions: import("@angular/core").InputSignal<SortPickOption[]>;
+    /** Whether the grid already sits on its default ordering — gates the reset row, nothing else. */
+    readonly sortIsDefault: import("@angular/core").InputSignal<boolean>;
     /** Asked for, never done here — see the button's comment. */
     readonly clearAll: import("@angular/core").OutputEmitterRef<void>;
+    /** A single-sort ask. Multi-sort stays a header gesture (ctrl-click); the picker replaces. */
+    readonly sortPick: import("@angular/core").OutputEmitterRef<SortMeta>;
+    /** Back to the owner's default ordering — the owner knows what that resolves to, not the bar. */
+    readonly sortReset: 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;
@@ -45,6 +58,7 @@ export declare class SpiderlyFilterBarComponent {
      */
     readonly controlTemplates: import("@angular/core").InputSignal<QueryList<SpiderlyFilterTemplateDirective>>;
     readonly isAddOpen: import("@angular/core").WritableSignal<boolean>;
+    readonly isSortOpen: 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. */
@@ -81,6 +95,23 @@ export declare class SpiderlyFilterBarComponent {
     }[]>;
     /** Opens a filter's control. Where it renders, and why not a popover: the template comment. */
     startEditing(id: string): void;
+    /**
+     * The menu's rows: each option decorated with its ACTIVE direction's arrow (any key, not
+     * just the primary), or null. A `computed`, not a per-row method call in the binding — the
+     * popover's content is projected, so it change-detects even while closed, and a `find` per
+     * option per pass is exactly what `operatorChoices` documents against.
+     */
+    readonly sortRows: import("@angular/core").Signal<{
+        arrow: string;
+        field: string;
+        label: string;
+    }[]>;
+    /**
+     * Ascending first; picking the already-ascending primary flips it. The direction is decided
+     * HERE so the owner applies exactly what the menu showed — an owner guessing "toggle" from its
+     * own state could disagree with a stale menu after a concurrent header click.
+     */
+    pickSort(option: SortPickOption): 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;
@@ -128,5 +159,5 @@ export declare class SpiderlyFilterBarComponent {
      */
     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>;
+    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; }; "sortOptions": { "alias": "sortOptions"; "required": false; "isSignal": true; }; "sortIsDefault": { "alias": "sortIsDefault"; "required": false; "isSignal": true; }; "controlTemplates": { "alias": "controlTemplates"; "required": false; "isSignal": true; }; }, { "clearAll": "clearAll"; "sortPick": "sortPick"; "sortReset": "sortReset"; }, never, never, true, never>;
 }

package/package.json

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

package/styles/filters/spiderly-filter-bar.component.scss

@@ -147,12 +147,49 @@
   font-size: 0.875rem;
 }
 
+// The picker's trigger — same chip, now a button. bare-button resets the UA chrome; the hover
+// underline mirrors the filter chips' edit affordance so "this opens something" reads the same
+// across the bar.
+button.sort-chip {
+  @include bare-button();
+  cursor: pointer;
+
+  &:hover .sort-chip-key,
+  &:hover .sort-chip-label {
+    text-decoration: underline;
+  }
+}
+
+.sort-chip-caret {
+  font-size: 0.65rem;
+}
+
 .sort-chip-key {
   // The direction arrow is the non-colour channel; the priority is the reading order, which is
   // the thing the scattered header icons could never show.
   color: var(--p-text-color);
 }
 
+// Teleported with its popover into document.body, so TOP LEVEL like the add menu above it
+// (Angular/CLAUDE.md → overlay styling); pinned by the "sort menu styles survive the body
+// teleport" spec. Inherits .filter-add-option for the row look.
+.sort-menu-option {
+  display: flex;
+  justify-content: space-between;
+  align-items: center;
+  gap: 12px;
+}
+
+.sort-menu-direction {
+  color: var(--p-primary-color);
+}
+
+.sort-menu-reset {
+  border-top: 1px solid var(--p-content-border-color);
+  border-radius: 0;
+  color: var(--p-text-muted-color);
+}
+
 .filter-bar-clear {
   // Pushed to the far end, away from the chips: a destructive action next to the x it resembles
   // is how a single chip gets removed by someone reaching for all of them. It is also the LAST