@svgrid/enterprise 2.6.1 → 2.6.2

package/dist/node/studio.js

@@ -1,4 +1,4 @@
-import "@svgrid/grid/filtering";
+import { isRangeOperator, isSetOperator, isValuelessOperator } from "@svgrid/grid/filtering";
 import { defaultThemePreset, getThemePreset, resolveThemeTokens as resolveThemeTokens$1, themePresets } from "@svgrid/grid/themes";
 //#region src/schema.ts
 /** `first_name` / `firstName` / `first-name` -> `First Name`. */
@@ -1932,6 +1932,21 @@ function scaffoldApp(schemas, options = {}) {
 }
 //#endregion
 //#region src/expressions/expression-columns.ts
+/**
+* Column metadata for the expression layer - the small, self-contained operator
+* catalogue the editor draws from, plus name <-> id resolution for the
+* `[Bracketed Name]` reference syntax.
+*
+* The operator set mirrors the grid's own filter row (text / number / date),
+* so an expression's operators line up with what a user already knows from the
+* column menu.
+*
+* Identity and input-shape semantics come from the grid's shared catalogue, so
+* the two surfaces cannot disagree about which operators exist or which need a
+* chip input / no input / a second value. Labels and ordering stay local on
+* purpose: the editor leads with `Equals` where the filter menu leads with
+* `Contains`, and each is right for its context.
+*/
 var TEXT = ["text"];
 var NUM = ["number"];
 var DATES = ["date", "datetime"];
@@ -1992,34 +2007,34 @@ var OPERATORS = [
 	{
 		value: "between",
 		label: "Between",
-		types: [...NUM, ...DATES],
-		range: true
+		types: [...NUM, ...DATES]
 	},
 	{
 		value: "in",
 		label: "In",
-		types: ["text", "number"],
-		set: true
+		types: ["text", "number"]
 	},
 	{
 		value: "notIn",
 		label: "Not in",
-		types: ["text", "number"],
-		set: true
+		types: ["text", "number"]
 	},
 	{
 		value: "isBlank",
 		label: "Is blank",
-		types: ALL,
-		valueless: true
+		types: ALL
 	},
 	{
 		value: "isNotBlank",
 		label: "Is not blank",
-		types: ALL,
-		valueless: true
+		types: ALL
 	}
-];
+].map((op) => ({
+	...op,
+	...isValuelessOperator(op.value) ? { valueless: true } : {},
+	...isSetOperator(op.value) ? { set: true } : {},
+	...isRangeOperator(op.value) ? { range: true } : {}
+}));
 new Map(OPERATORS.map((op) => [op.value, op]));
 //#endregion
 //#region src/expressions/parse.ts
@@ -8607,6 +8622,20 @@ var GENERATED_UI_SURFACE = {
 				"type": "boolean",
 				"group": "common"
 			},
+			{
+				"key": "groupBy",
+				"label": "Group By",
+				"type": "json",
+				"description": "Group the rows by these column ids, outermost first - `['region', 'country']` rolls country up inside region. ```svelte <SvGrid {data} {columns} {features} groupBy={['department']} /> ``` The prop seeds the group-by list and re-applies whenever it changes, so it works both as initial state and as a controlled value. The column menu and `api.setGroupBy()` write the same state; a change from either survives until this prop's own value changes. Ignored when `treeData` is set - a row cannot be both a hierarchy node and bucketed under a group banner.",
+				"group": "common"
+			},
+			{
+				"key": "expanded",
+				"label": "Expanded",
+				"type": "json",
+				"description": "Which group / tree rows are expanded, keyed by row id. Expansion is owned by the engine by default; pass this prop to hoist it (saved views, \"expand everything on load\", persisted UI state). Like `groupBy` it seeds the state and re-applies whenever it changes. Group row ids are built from the grouping path, not the display label: `group_department_Engineering`, and one level deeper `group_department_Engineering_role_Senior`. Tree rows key off the engine's row id instead (set `getRowId` to make that your own id). Prefer capturing the map from `onExpandedChange` over hand-building these keys.",
+				"group": "common"
+			},
 			{
 				"key": "groupFooters",
 				"label": "Group Footers",
@@ -9006,6 +9035,13 @@ var GENERATED_UI_SURFACE = {
 				"description": "The sort state to start in - `{ id, desc }` entries. Use with `externalSort` when the initial ordering is decided server-side (e.g. a URL `?sort=` param read in a SvelteKit `load`), so the header sort indicators match the already- sorted data on first render. Applied once at mount; user sorting takes over.",
 				"group": "common"
 			},
+			{
+				"key": "initialAdvancedFilter",
+				"label": "Initial Advanced Filter",
+				"type": "json",
+				"description": "The advanced-filter expression to start in (Pro). Applied once at mount; change it afterwards through `api.setAdvancedFilter()`. Filtering only happens once `@svgrid/enterprise`'s `enableAdvancedFilter()` has registered a compiler - without it the expression is stored and reported but no rows are removed, so the free grid degrades to a no-op rather than to a wrong row set.",
+				"group": "common"
+			},
 			{
 				"key": "externalFilter",
 				"label": "External Filter",
@@ -9156,6 +9192,12 @@ var GENERATED_UI_SURFACE = {
 				"prop": "onPivotModeChange",
 				"description": "Fired when the in-grid Pivot toggle flips `pivotMode`."
 			},
+			{
+				"key": "expandedChange",
+				"label": "Expanded Change",
+				"prop": "onExpandedChange",
+				"description": "Fired whenever the expanded set changes - chevron clicks, `api.setRowExpanded()`, `expandAllGroups()` / `collapseAllGroups()`. Receives the full next map, so it can be written straight back into `expanded` for a controlled setup."
+			},
 			{
 				"key": "paginationChange",
 				"label": "Pagination Change",
@@ -9186,6 +9228,12 @@ var GENERATED_UI_SURFACE = {
 				"prop": "onSortingChange",
 				"description": "Fires whenever the sort clauses change. Receives the new array of `{ id, desc }` entries. Pair with `externalSort={true}` when the consumer wants to own the row ordering."
 			},
+			{
+				"key": "advancedFilterChange",
+				"label": "Advanced Filter Change",
+				"prop": "onAdvancedFilterChange",
+				"description": "Fires whenever the advanced-filter expression changes, whatever changed it: `api.setAdvancedFilter()`, `clearAllFilters()`, or the toolbar's clear control. The panel that authors the expression is mounted by you, outside the grid, so it cannot see a change the grid made on its own. Without this, clearing from the toolbar leaves that panel showing a filter the grid is no longer applying. Feed this back into the panel's `expression` prop to keep them agreeing."
+			},
 			{
 				"key": "filtersChange",
 				"label": "Filters Change",
@@ -15740,7 +15788,7 @@ function hasFieldConditions(schema) {
 *
 * `version.test.ts` asserts this matches `package.json`, so the two cannot drift.
 */
-var SVGRID_VERSION = "2.6.0";
+var SVGRID_VERSION = "2.6.2";
 //#endregion
 //#region src/studio/emit-project.ts
 var has = (blocks, kind) => blocks.some((b) => b.config.kind === kind);

package/dist/sources/rest.js

@@ -23,6 +23,31 @@ function defaultBuildQuery(request) {
         params.search = search;
     for (const p of predicates)
         params[p.column] = encodePredicate(p);
+    // ---- Server-side grouping ----------------------------------------------
+    // The grid asks for one level at a time. The path already chosen is sent as
+    // ordinary equality filters (the same shape any other filter uses), so an
+    // endpoint that already understands `?region=eq:EMEA` only needs to learn
+    // `groupBy` and `aggregate`.
+    //
+    //   ?groupBy=region&aggregate=sum:amount,count:id
+    //
+    // and, one level down:
+    //
+    //   ?groupBy=rep&region=eq:EMEA&aggregate=sum:amount
+    //
+    // The response is then one object per distinct key, each carrying the
+    // aggregate under its SOURCE column name - that is where the grid reads it.
+    const groupCols = request.groupBy ?? [];
+    const groupKeys = request.groupKeys ?? [];
+    for (let i = 0; i < groupKeys.length && i < groupCols.length; i += 1) {
+        params[groupCols[i]] = `eq:${groupKeys[i]}`;
+    }
+    if (groupKeys.length < groupCols.length) {
+        params.groupBy = groupCols[groupKeys.length];
+        const aggs = request.aggregations ?? [];
+        if (aggs.length)
+            params.aggregate = aggs.map((a) => `${a.fn}:${a.col}`).join(',');
+    }
     return params;
 }
 function defaultParse(body, response) {

package/dist/sources/supabase.js

@@ -10,7 +10,33 @@ export function createSupabaseDataSource(config) {
         schema.fields.filter((f) => f.type === 'text' || f.type === 'enum').map((f) => String(f.field));
     return {
         async getRows(request) {
-            let q = client.from(table).select('*', { count: 'exact' });
+            // ---- Server-side grouping -------------------------------------------
+            // The grid asks one level at a time. The already-chosen path becomes
+            // ordinary `.eq()` filters below; at this level we ask PostgREST for the
+            // group column plus aggregates, which implicitly groups by the
+            // non-aggregate columns in `select`.
+            //
+            // Each aggregate is aliased back to its SOURCE column name, because that
+            // is the key the grid reads it from on the group row.
+            //
+            // REQUIRES PostgREST 12+ with aggregate functions enabled
+            // (`db-aggregates-enabled`, off by default on some Supabase projects). On
+            // an older or restricted instance the request errors rather than silently
+            // returning ungrouped rows, so the failure is visible.
+            const groupCols = request.groupBy ?? [];
+            const groupKeys = request.groupKeys ?? [];
+            const groupField = groupKeys.length < groupCols.length ? groupCols[groupKeys.length] : undefined;
+            const selectExpr = groupField
+                ? [
+                    groupField,
+                    ...(request.aggregations ?? []).map((a) => a.fn === 'count' ? `${a.col}:count()` : `${a.col}:${a.col}.${a.fn}()`),
+                ].join(',')
+                : '*';
+            let q = client.from(table).select(selectExpr, { count: 'exact' });
+            // The path constrains the rows before grouping.
+            for (let i = 0; i < groupKeys.length && i < groupCols.length; i += 1) {
+                q = q.eq(groupCols[i], groupKeys[i]);
+            }
             const { predicates, search } = normalizeFilters(request.filterModel);
             for (const p of predicates) {
                 switch (p.op) {
@@ -44,8 +70,28 @@ export function createSupabaseDataSource(config) {
                 const term = sanitize(search);
                 q = q.or(searchColumns.map((c) => `${c}.ilike.%${term}%`).join(','));
             }
-            for (const s of request.sortModel)
-                q = q.order(s.id, { ascending: !s.desc });
+            // When grouping, only columns the grouped select actually produces can be
+            // ordered on - PostgREST rejects an ORDER BY over a column that is
+            // neither grouped nor aggregated. Fall back to the group key so the
+            // result has a stable order either way.
+            if (groupField) {
+                const produced = new Set([
+                    groupField,
+                    ...(request.aggregations ?? []).map((a) => a.col),
+                ]);
+                const usable = request.sortModel.filter((s) => produced.has(s.id));
+                if (usable.length) {
+                    for (const s of usable)
+                        q = q.order(s.id, { ascending: !s.desc });
+                }
+                else {
+                    q = q.order(groupField, { ascending: true });
+                }
+            }
+            else {
+                for (const s of request.sortModel)
+                    q = q.order(s.id, { ascending: !s.desc });
+            }
             const { data, count, error } = await q.range(request.startRow, request.endRow - 1);
             if (error)
                 throw new Error(error.message);