spiderly 19.12.0 → 19.12.1

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';
@@ -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,74 @@ 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 sort this view asks for: the operator's stored override, else its declared sort. */
+    private viewSort;
+    /**
+     * Records the current sort as the active view's override — called from the EXPLICIT sort
+     * gestures only (header click, menu sort, Clear filters), 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 first, then the declared sort;
+     * a view stating no preference keeps the ordering already there (the pre-decision-10-sort
+     * behavior, and the least surprising for the tab an operator never sorted). 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 +482,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
@@ -579,6 +696,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;
@@ -677,6 +803,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 +838,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 +885,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

package/package.json

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