Observation, measured while implementing #5269 on origin/main @ 3fbbea1f3. Filed unassigned, not claiming, and deliberately not fixed there — #5269 owns the table.columns forwarding lines only, and this is a declared-surface question, not a forwarding one.
What was measured
ObjectView.generateViewSchema switches on eight view types and returns a renderer schema for each:
kanban · calendar · gallery · timeline · gantt · map · tree · chart
The type that an AUTHOR uses to select one admits six of them:
ObjectViewSchema.defaultViewType (packages/types/src/objectql.ts) — 'grid' | 'kanban' | 'gallery' | 'calendar' | 'timeline' | 'gantt' | 'map'NamedListView.type (same file) — the same seven-value union
Neither spells tree or chart. The only segment that can is the views PROP on the component (views?: Array< { … type: ViewType } >), and ViewType (packages/types/src/views.ts) does include both:
export type ViewType = 'list' | 'detail' | 'grid' | 'kanban' | 'calendar' | 'timeline' | 'map' | 'gallery' | 'gantt' | 'chart' | 'tree';
So currentViewType can only ever be tree or chart when a HOST composes ObjectView with a views prop. From authored metadata — the path the docs teach — those two branches are dead code, including the object-tree branch's own viewOptions.tree.* config surface (parentField, labelField, defaultExpandedDepth) and the whole ADR-0021 dataset-bound chart branch.
Why it is worth recording rather than assuming intentional
Both branches carry real, maintained config surfaces and their own comments, which reads as "authorable" to the next person. The tree view was added as a metadata-driven object view type (#1885, closed), and the chart branch cites ADR-0021 — neither reads like a host-composition-only affordance. If they ARE host-only by design, that is the same class of ruling #5097 made for the 27 renderListView keys, and it wants saying somewhere a census can read; if they are not, defaultViewType / NamedListView.type are missing two members.
Adjacent, same file, same shape: the iconMap inside viewSwitcherSchema has a chart entry but no tree one, so a host-supplied tree view falls back to the 'table' icon. (#2916 fixed the missing chart key in that map and is closed; tree was never added.)
Not fixed here
Deciding this is a contract question — either declare two more members on two authored unions, or record the host-only exemption — not something to guess inside a forwarding fix. No behaviour in #5269's PR depends on it: that PR's tree coverage drives the branch through the views prop, which is the reachable path either way.
Dedup
Searched open issues for defaultViewType, the enum-vs-switch shape, and plugin-view surface cards. Nothing open covers it. Related and closed: #2916 (the same file's iconMap missing chart), #1885 (tree view added), #5097 (the host-composition-surface ruling this would follow if the branches are host-only).
Observation, measured while implementing #5269 on
origin/main@3fbbea1f3. Filed unassigned, not claiming, and deliberately not fixed there — #5269 owns thetable.columnsforwarding lines only, and this is a declared-surface question, not a forwarding one.What was measured
ObjectView.generateViewSchemaswitches on eight view types and returns a renderer schema for each:The type that an AUTHOR uses to select one admits six of them:
ObjectViewSchema.defaultViewType(packages/types/src/objectql.ts) —'grid' | 'kanban' | 'gallery' | 'calendar' | 'timeline' | 'gantt' | 'map'NamedListView.type(same file) — the same seven-value unionNeither spells
treeorchart. The only segment that can is theviewsPROP on the component (views?: Array< { … type: ViewType } >), andViewType(packages/types/src/views.ts) does include both:So
currentViewTypecan only ever betreeorchartwhen a HOST composesObjectViewwith aviewsprop. From authored metadata — the path the docs teach — those two branches are dead code, including theobject-treebranch's ownviewOptions.tree.*config surface (parentField,labelField,defaultExpandedDepth) and the whole ADR-0021 dataset-boundchartbranch.Why it is worth recording rather than assuming intentional
Both branches carry real, maintained config surfaces and their own comments, which reads as "authorable" to the next person. The tree view was added as a metadata-driven object view type (#1885, closed), and the
chartbranch cites ADR-0021 — neither reads like a host-composition-only affordance. If they ARE host-only by design, that is the same class of ruling #5097 made for the 27renderListViewkeys, and it wants saying somewhere a census can read; if they are not,defaultViewType/NamedListView.typeare missing two members.Adjacent, same file, same shape: the
iconMapinsideviewSwitcherSchemahas achartentry but notreeone, so a host-supplied tree view falls back to the'table'icon. (#2916 fixed the missingchartkey in that map and is closed;treewas never added.)Not fixed here
Deciding this is a contract question — either declare two more members on two authored unions, or record the host-only exemption — not something to guess inside a forwarding fix. No behaviour in #5269's PR depends on it: that PR's tree coverage drives the branch through the
viewsprop, which is the reachable path either way.Dedup
Searched open issues for
defaultViewType, the enum-vs-switch shape, and plugin-view surface cards. Nothing open covers it. Related and closed: #2916 (the same file'siconMapmissingchart), #1885 (tree view added), #5097 (the host-composition-surface ruling this would follow if the branches are host-only).