Uh oh!
There was an error while loading. Please reload this page.
fix(plugin-view): forward the canonical table.columns on the non-grid paths - #5319
Merged
os-support-ai merged 2 commits intoAug 19, 2026
Merged
Conversation
…id paths (#5269) `ObjectViewSchema.table` inherits from `ObjectGridSchema`, where `columns` is canonical and `fields` is `@deprecated Use columns instead`. Only one of the file's three field-list read points consulted `table.columns` — the grid one. `generateViewSchema`'s shared `baseProps` and the delegated `renderListView` schema read `table.fields` alone, so `table: { columns: [...] }` produced an empty field list off the grid path from a schema that compiled and read correctly. Both sites now read the canonical key first, keeping the deprecated one as a working alias (the shape objectui#5102 settled for its four pairs). Forwarding, not translation; precedence unchanged. `schema.table?.columns` joins the `generateViewSchema` dependency list alongside the read. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE
…e non-grid slot (#5269) The non-grid `baseProps` slot is a names slot — both segments ahead of the `table` one declare `string[]`, and `ObjectKanban` indexes the record by each entry — while `table.columns` is `string[] | ListColumn[]`. Forwarding the object form raw would have handed kanban a non-empty card field list naming nothing, which renders emptier than the bug this card fixes: a non-empty list suppresses ObjectKanban's `highlightFields` fallback. Same failure mode as objectui#5270 (a value in a slot whose declared shape it lacks), answered the same way, at the boundary. `columnIdentity` (@object-ui/core) is the fold ObjectGrid already applies to this very value on the grid path, so the two paths now resolve one authored `table.columns` identically. `undefined`, never `[]`, when nothing resolves — otherwise a truthy empty array would stop the `||` chain short of the deprecated `table.fields`. The delegated `list-view` slot declares the same union and keeps taking the value raw. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RV6yuVCxymHYE16PL9vQkE
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-support-ai
marked this pull request as ready for review
August 19, 2026 14:34
Uh oh!
There was an error while loading. Please reload this page.
os-support-ai
deleted the
claude/issue-5269-objectview-table-columns-forwarding
branch
August 19, 2026 14:35
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#5269
ObjectViewSchema.tableisPartial< Omit< ObjectGridSchema, 'type' | 'objectName' > >, wherecolumnsis the canonical spelling andfieldscarries@deprecated Use columns instead.ObjectViewdoes not spreadtable; it forwards a hand-written whitelist, and that whitelist had exactly one read oftable.columnsin the file — the grid one. The other two field-list read points took the deprecated key alone, sotable: { columns: [...] }— the shape the type recommends — produced an empty field list off the grid path from a schema that compiled and read correctly. Same silent-success shape as #5102, different mechanism: not a whitelist that knows only legacy spellings, but one that disagreed with itself between two rendering paths.Both sites now read the canonical key first and keep the deprecated one as a working alias, the shape #5102 settled for its four pairs. Precedence is unchanged: a named view's
columns, then the active view's, then thetablesegment.schema.table?.columnsalso joins thegenerateViewSchemadependency list alongside the new read.Re-derived against current
origin/main(3fbbea1f3), because the card is staleThe region was reworked twice today (#5102, then #5270 / PR #5294). Card vs. tree, measured:
3fbbea1f3:842baseProps:842, and stilltable?.fieldsonly — confirmed:1056/:1057grid:1085/:1086, unchanged in substance:1247delegated:1284, stilltable?.fieldsonly — confirmeduseCallbackdependency list at:1021readsschema.table?.fieldstoo, and a memo that reads a key without depending on it keeps serving a field list the author has already replacedThe defect stands. Its reach does not, in either direction — the affected surfaces were measured rather than taken from the card:
baseProps.fieldsbecomescardFields, whichObjectKanbanreads.ObjectTreereadsschema.fields, fed from the samebaseProps.renderListView— real.ListViewreadsschema.columnsas its whole column set..fieldsin them isobjectDef.fields(object metadata) or gallery'sschema.grouping.fields. The forwarded value is inert there, before this change and after it. No ceremonial tests were added for them; the measurement is recorded in the test file header instead. (Each zero was counter-probed with.titleFieldin the same file — the first counter-probe caught a regex of mine that read zero onObjectCalendarfor the wrong reason.)One shape question the fix raised, answered at the boundary
table.columnsisstring[] | ListColumn[], and the two slots disagree about which half they can hold:list-viewcolumnsslot declares the same union andListViewreads both, so it takes the value raw — flattening there would throw away thelabel/widththe author wrote;basePropsslot is a names slot: both segments ahead oftabledeclarestring[], andObjectKanbanindexes the record by each entry (resolveKanbanCardFieldscasts straight tostring[]).Raw forwarding into the second one would have handed kanban a non-empty card field list naming nothing — which renders emptier than the bug being fixed, because a non-empty list suppresses
ObjectKanban'shighlightFieldsfallback. That is #5270's failure again (a value in a slot whose declared shape it lacks), so it is answered the same way:columnIdentityfrom@object-ui/core, the repo's converged identity reader (#3104) and the very foldObjectGridapplies to this same value when deriving$select. One authoredtable.columnsnow resolves identically on both paths. It returnsundefined, never[], when nothing resolves — a truthy empty array would stop the||chain short oftable.fields.No new spelling becomes acceptable: the accepted set is what
columnIdentityalready accepts everywhere else in the repo, and the canonical key being honoured here was already declared.Verification
Run from the repository root (plugin-view owns a standalone
vitest.config.ts, so the invocation guard does not cover a package-cwd run here).pnpm exec vitest run packages/plugin-view— 16 files, 172 tests, all green at942197219, including theobjectViewHostSurfacefence pin (my edits add no(schema as any)read, so the derived key set is unchanged),canonicalTableKeys(ObjectViewSchema的table/form子配置类型零声明成员(Omit 被索引签名塌掉),且 ObjectView 的转发白名单钉在 ObjectGridSchema 的 legacy 键上 —— 规范键 pagination/selection/filter/sort 全部不读 #5102) andnamedViewSortArity(A named view'ssortarray is forwarded intogridSchema.defaultSort, declared a SINGLE{ field, order }— ObjectGrid re-wraps it andparseSchemaSortdrops it, so the grid shows no sort at all #5270).pnpm --filter @object-ui/plugin-view type-check— green (tsc --noEmit && tsc -p tsconfig.test.json; the script is spelledtype-checkin this repo, and the run echoes it, so this is not a zero-match pass).pnpm --filter @object-ui/plugin-view lint— 0 errors.check:control-bytes,check:phantom-deps,check:self-import,check:esm-specifiers,scripts/check-changeset-no-major.mjs— all green at942197219.No build artifact sits between the edit and the thing under test: the suite imports the subject as
../ObjectView(source), and the root Vitest config aliases every@object-ui/*specifier —@object-ui/core, wherecolumnIdentitycomes from — topackages/*/src. Thedist/built fortype-checkis not on the test's resolution path.Reverse-verification (fix reverted with the tests kept, prediction written before the run): predicted 7 red and 7 green-on-both-legs; observed exactly that, with the predicted values.
Red, all seven pinning the defect: kanban
forwards table.columns as the kanban card fields([]), kanbanprefers the canonical … over the deprecated(['owner']), kanbanresolves the ListColumn[] form … to field NAMES([]), treeforwards table.columns as the tree view fields(undefined), delegatedhands over a canonical table.columns(undefined), delegatedhands over the ListColumn[] form … unchanged(undefined), delegatedprefers the canonical … over the deprecated(['owner']).Green on both legs, so stated rather than counted — they pin the halves that must not change, not the defect: the three
still forwards the deprecated table.fieldsaliases (kanban / tree / delegated), the twokeeps a named view outranking the table segmentprecedence tests, the grid-path control, andfalls through to table.fields when no column entry names a field(green before for a different reason — the canonical key was ignored entirely).Generated by Claude Code
Generated by Claude Code