You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
finding(plugin-grid/docs): the published docs and skills teach { name, label } columns on a directly-authored object-grid, which ObjectGrid silently drops — before and after #5068 #5352
So the outcome is identical on both sides of PR5345. This is a pre-existing docs-vs-runtime divergence that #5068's census did not surface because that census was looking for the accessorKey/header spelling, not this one.
Why it is not merely a docs fix
ObjectGrid is not downstream of normalizeListViewSchema when an object-grid node is authored directly — its own test file says so (packages/plugin-grid/src/__tests__/columnIdentity.test.tsx, docblock). So the name → field fold that rescues a list view's columns (normalizeColumnIdentities, #3104) never runs here. The same { name: 'status' } column therefore does reach $select (getSelectFields resolves through columnIdentity, which accepts name) while not reaching the rendered column set: the server is asked for the field and the user is never shown it.
That asymmetry is the part worth a decision — whether the fix is the docs, the fold, or the filter.
Recheck
sed -n '745,757p' content/docs/api/schema-reference.md
sed -n '298,312p' skills/objectui/guides/page-builder.md
sed -n '1448,1460p' packages/plugin-grid/src/ObjectGrid.tsx # the field filter
sed -n '1652,1658p' packages/plugin-grid/src/ObjectGrid.tsx # the string arm's filter
sed -n '9,21p' packages/plugin-grid/src/__tests__/columnIdentity.test.tsx
Grading
finding, not pm:queue. Related: #5068, #5349 (the same silence, asked as a diagnostics question), #5120.
Found while running #5120's census (not claiming; observation class). Baseline objectui
main@ 9c60144, i.e. after PR5345 (#5068) landed.The fact
Two published corpora author
object-gridcolumns in thenamespelling:content/docs/api/schema-reference.md:748-755— a mixed array:"columns": ["name", "email", "company", "phone", { "name": "status", "label": "Status", "sortable": true }]skills/objectui/guides/page-builder.md:304— all-object:{ "name": "name", "label": "Name", "type": "text" }, etc.ObjectGridrenders neither. Both shapes are dropped silently — no throw, no console line, no empty header cell; the column is simply absent.Not a #5068 regression — verified both paths
Worth stating explicitly, because the timing invites the wrong conclusion:
ObjectGridSchema.columns上容忍未声明的accessorKey/header拼写 —— 声明类型是 strict 的 ListColumn,#3104 的列身份门禁结构上看不见这条支路 #5068, an all-object array reaches the ListColumn arm, whose filter iscol?.field && typeof col.field === 'string'. A{ name, label }column has nofield, so it is filtered out.ObjectGridSchema.columns上容忍未声明的accessorKey/header拼写 —— 声明类型是 strict 的 ListColumn,#3104 的列身份门禁结构上看不见这条支路 #5068, the same array met the retired dispatch:'accessorKey' in firstCol→ no;'field' in firstCol→ no; so it fell out of the object block entirely and into the string arm, whose filter istypeof fieldName === 'string'— which drops it too.schema-reference.md) hascols[0]as a string, sotypeof cols[0] === 'object'is false and it took the string arm both before and after; the one object entry is dropped by that sametypeof === 'string'filter, unchanged by finding(plugin-grid): ObjectGrid 在ObjectGridSchema.columns上容忍未声明的accessorKey/header拼写 —— 声明类型是 strict 的 ListColumn,#3104 的列身份门禁结构上看不见这条支路 #5068.So the outcome is identical on both sides of PR5345. This is a pre-existing docs-vs-runtime divergence that #5068's census did not surface because that census was looking for the
accessorKey/headerspelling, not this one.Why it is not merely a docs fix
ObjectGridis not downstream ofnormalizeListViewSchemawhen anobject-gridnode is authored directly — its own test file says so (packages/plugin-grid/src/__tests__/columnIdentity.test.tsx, docblock). So thename→fieldfold that rescues alistview's columns (normalizeColumnIdentities, #3104) never runs here. The same{ name: 'status' }column therefore does reach$select(getSelectFieldsresolves throughcolumnIdentity, which acceptsname) while not reaching the rendered column set: the server is asked for the field and the user is never shown it.That asymmetry is the part worth a decision — whether the fix is the docs, the fold, or the filter.
Recheck
Grading
finding, notpm:queue. Related: #5068, #5349 (the same silence, asked as a diagnostics question), #5120.