Found while implementing #5102. Filed unassigned, not claiming. Deliberately NOT fixed there — #5102's ruling scoped the work to the table segment of the forwarding chains, and its dispatch explicitly ⛔ ruled the two segments ahead of table (currentNamedViewConfig, activeView) out of bounds. This defect lives entirely in those two segments and is unchanged on both sides of that PR's diff.
The shape mismatch
packages/plugin-view/src/ObjectView.tsxgridSchema (:1055):
defaultSort: viewSort || schema.table?.defaultSort,
where viewSort resolves currentNamedViewConfig?.sort || activeView?.sort.
The two sides are different arities:
NamedListView.sort (packages/types/src/objectql.ts:1579) is Array< { field, order } > — an array.ObjectGridSchema.defaultSort (packages/types/src/objectql.ts legacy block) is a single object { field: string; order: 'asc' | 'desc' }.
So an array is placed in a slot declared to hold one object. The declaration collapse described in #5102 (table is Partial< Omit< ObjectGridSchema, … > >, flattened to a bare index signature) is why no compile error appears.
What the consumer then does
packages/plugin-grid/src/ObjectGrid.tsx:
- Header/display sort,
:2701: parseSchemaSort(schemaSort ?? (schema.defaultSort ? [schema.defaultSort] : undefined)). With defaultSort already an array this wraps to [[{ field, order }]]. parseSchemaSort (:69) iterates the outer array and, per entry, accepts a string or an object with a string field; a nested array is neither, so the entry is skipped and the result is [] — no sort arrow, no declared sort on screen. - Fetch path,
:1121: params.$orderby = \${(schema.defaultSort as any).field} ${(schema.defaultSort as any).order}`— on an array both reads areundefined, producing the literal string "undefined undefined"as$orderby`.
Both are reachable only when schemaSort (the canonical sort slot) is absent, which is the case whenever a named view supplies the sort.
Measured
Observable through ObjectView with a listViews entry carrying sort: [{ field: 'name', order: 'desc' }]: the forwarded gridSchema.defaultSort is [{ field: 'name', order: 'desc' }] — an array in the single-object slot. Pinned as current behaviour (explicitly "unchanged by #5102") in packages/plugin-view/src/__tests__/ObjectView.canonicalTableKeys.test.tsx, in the a named view still outranks the table segment block. That pin should be updated, not deleted, by whoever fixes this.
Suggested direction (not adjudicated)
The canonically shaped fix is to route the view segments into gridSchema.sort — which is declared string | SortConfig[] and therefore already accepts the array — instead of the deprecated single-object slot. Note this is not a pure move: ObjectGrid treats the two slots differently on the filter side too (canonical filter is lowered through toFilterNode, legacy defaultFilters is raw-assigned at :1100), so the filter half of the same pair needs its own wire-shape check before being moved with it.
Dedup
Searched open issues (defaultSort, named view sort, parseSchemaSort, plus the file path). Nothing on this. Related: #4869 (finding, open) — the non-grid fetch path passes $orderby through without the shared sort sink; adjacent but a different path and a different mechanism, and it remains accurate after #5102. Also #5102 (the table segment of these same chains).
Found while implementing #5102. Filed unassigned, not claiming. Deliberately NOT fixed there — #5102's ruling scoped the work to the
tablesegment of the forwarding chains, and its dispatch explicitly ⛔ ruled the two segments ahead oftable(currentNamedViewConfig,activeView) out of bounds. This defect lives entirely in those two segments and is unchanged on both sides of that PR's diff.The shape mismatch
packages/plugin-view/src/ObjectView.tsxgridSchema(:1055):where
viewSortresolvescurrentNamedViewConfig?.sort || activeView?.sort.The two sides are different arities:
NamedListView.sort(packages/types/src/objectql.ts:1579) isArray< { field, order } >— an array.ObjectGridSchema.defaultSort(packages/types/src/objectql.tslegacy block) is a single object{ field: string; order: 'asc' | 'desc' }.So an array is placed in a slot declared to hold one object. The declaration collapse described in #5102 (
tableisPartial< Omit< ObjectGridSchema, … > >, flattened to a bare index signature) is why no compile error appears.What the consumer then does
packages/plugin-grid/src/ObjectGrid.tsx::2701:parseSchemaSort(schemaSort ?? (schema.defaultSort ? [schema.defaultSort] : undefined)). WithdefaultSortalready an array this wraps to[[{ field, order }]].parseSchemaSort(:69) iterates the outer array and, per entry, accepts a string or an object with a stringfield; a nested array is neither, so the entry is skipped and the result is[]— no sort arrow, no declared sort on screen.:1121:params.$orderby = \${(schema.defaultSort as any).field} ${(schema.defaultSort as any).order}`— on an array both reads areundefined, producing the literal string"undefined undefined"as$orderby`.Both are reachable only when
schemaSort(the canonicalsortslot) is absent, which is the case whenever a named view supplies the sort.Measured
Observable through ObjectView with a
listViewsentry carryingsort: [{ field: 'name', order: 'desc' }]: the forwardedgridSchema.defaultSortis[{ field: 'name', order: 'desc' }]— an array in the single-object slot. Pinned as current behaviour (explicitly "unchanged by #5102") inpackages/plugin-view/src/__tests__/ObjectView.canonicalTableKeys.test.tsx, in thea named view still outranks the table segmentblock. That pin should be updated, not deleted, by whoever fixes this.Suggested direction (not adjudicated)
The canonically shaped fix is to route the view segments into
gridSchema.sort— which is declaredstring | SortConfig[]and therefore already accepts the array — instead of the deprecated single-object slot. Note this is not a pure move:ObjectGridtreats the two slots differently on the filter side too (canonicalfilteris lowered throughtoFilterNode, legacydefaultFiltersis raw-assigned at:1100), so the filter half of the same pair needs its own wire-shape check before being moved with it.Dedup
Searched open issues (
defaultSort,named view sort,parseSchemaSort, plus the file path). Nothing on this. Related: #4869 (finding, open) — the non-grid fetch path passes$orderbythrough without the shared sort sink; adjacent but a different path and a different mechanism, and it remains accurate after #5102. Also #5102 (thetablesegment of these same chains).