Measured while implementing half 1 of objectui#7210. Filed separately: objectui#7210 is about the paging footer and the missing ceiling; this is about a wrapper that silently drops every host prop, and it is the mechanism underneath that card rather than the card itself.
Filed unassigned. One half is a stale comment (certain), one half is dead code (certain), one half is a suspected user-visible consequence I did not measure and have marked as such.
Measured
packages/plugin-gantt/src/index.tsx:
export const ObjectGanttRenderer = elementDataSourceBlock(({ schema }) => {
const { dataSource } = useSchemaContext() || {};
return (
ElementDataSourceGate ...
{(bound) => ObjectGantt with schema={bound} dataSource={dataSource} }
);
});
It destructures { schema } only and hands the child exactly two props. Every sibling view wrapper destructures ({ schema, ...props }) and spreads {...props} onto its child:
| wrapper | forwards host props? |
|---|
plugin-gridObjectGridRenderer | yes |
plugin-kanbanObjectKanbanRenderer | yes |
plugin-calendarObjectCalendarRenderer | yes (through a declared, filtered hatch) |
plugin-mapObjectMapRenderer | yes |
plugin-treeObjectTreeRenderer | yes |
plugin-ganttObjectGanttRenderer | no |
Pinned behaviourally in packages/plugin-gantt/src/ObjectGantt.hostDataProp-7210.test.tsx (landing with objectui#7210's half 1): a host renders the block with data = 2 rows while the adapter answers 5, and the chart draws the adapter's 5.
Consequence 1 — a dead conditional (certain)
plugin-list/src/ListView.tsx hands its child {...(ganttOwnsData ? {} : { data })}. For a gantt that expression cannot matter: the prop is dropped either way. The ganttOwnsData flag still earns its keep through its other two effects (skipping ListView's own fetch for an api-provider gantt, and not flashing the skeleton), so this is one inert clause, not a dead flag.
Consequence 2 — a comment that is false (certain)
Directly above it:
// ListView must neither fetch schema.objectName rows for it nor pass its
// `data` prop down — the prop short-circuits the renderer's own fetch, so
// stale object rows would replace the endpoint's tree.
The prop does not short-circuit the renderer's own fetch, because the prop never reaches the renderer. ObjectGantt.reload's rest.data branch is real code, but nothing on the registry path can reach it. This is not a nit: believing that comment is exactly what makes objectui#7210's double fetch invisible on a read-through — it says the host feeds the chart, and the host does not.
Consequence 3 — SUSPECTED, not measured
ListView's baseProps also carries onRowClick: navigation.handleClick, plus rowHeight, hideRowHeightToggle and onRowSelect, and none of them can arrive either. If a gantt view's authored navigation config (drawer / modal / page) is meant to be honoured through that callback, it is not being honoured — but ObjectGantt owns a record drawer of its own, so it may simply not need it. Unverified. Someone should drive a gantt row click in a browser before this is treated as a defect.
⛔ What this card is NOT proposing
Do not read this as "spread {...props} and be done." Forwarding data would feed the chart the host's PAGE, capping a gantt at pagination.pageSize — a complete schedule becomes a quietly truncated one that still looks like a schedule. Whether a non-grid view may fetch unbounded at all is an open maintainer decision recorded on objectui#7210 (half 2) and escalated on objectui#5560; it is not settled by this card and must not be settled as a side effect of a prop-forwarding tidy-up. The two safe pieces here are the comment and the inert clause.
Refs: objectui#7210 (parent observation; halves 2 and 3 open there), objectui#7221 (the filter-dialect half).
Measured while implementing half 1 of objectui#7210. Filed separately: objectui#7210 is about the paging footer and the missing ceiling; this is about a wrapper that silently drops every host prop, and it is the mechanism underneath that card rather than the card itself.
Filed unassigned. One half is a stale comment (certain), one half is dead code (certain), one half is a suspected user-visible consequence I did not measure and have marked as such.
Measured
packages/plugin-gantt/src/index.tsx:It destructures
{ schema }only and hands the child exactly two props. Every sibling view wrapper destructures({ schema, ...props })and spreads{...props}onto its child:plugin-gridObjectGridRendererplugin-kanbanObjectKanbanRendererplugin-calendarObjectCalendarRendererplugin-mapObjectMapRendererplugin-treeObjectTreeRendererplugin-ganttObjectGanttRendererPinned behaviourally in
packages/plugin-gantt/src/ObjectGantt.hostDataProp-7210.test.tsx(landing with objectui#7210's half 1): a host renders the block withdata= 2 rows while the adapter answers 5, and the chart draws the adapter's 5.Consequence 1 — a dead conditional (certain)
plugin-list/src/ListView.tsxhands its child{...(ganttOwnsData ? {} : { data })}. For a gantt that expression cannot matter: the prop is dropped either way. TheganttOwnsDataflag still earns its keep through its other two effects (skippingListView's own fetch for an api-provider gantt, and not flashing the skeleton), so this is one inert clause, not a dead flag.Consequence 2 — a comment that is false (certain)
Directly above it:
The prop does not short-circuit the renderer's own fetch, because the prop never reaches the renderer.
ObjectGantt.reload'srest.databranch is real code, but nothing on the registry path can reach it. This is not a nit: believing that comment is exactly what makes objectui#7210's double fetch invisible on a read-through — it says the host feeds the chart, and the host does not.Consequence 3 — SUSPECTED, not measured
ListView'sbasePropsalso carriesonRowClick: navigation.handleClick, plusrowHeight,hideRowHeightToggleandonRowSelect, and none of them can arrive either. If a gantt view's authorednavigationconfig (drawer / modal / page) is meant to be honoured through that callback, it is not being honoured — butObjectGanttowns a record drawer of its own, so it may simply not need it. Unverified. Someone should drive a gantt row click in a browser before this is treated as a defect.⛔ What this card is NOT proposing
Do not read this as "spread
{...props}and be done." Forwardingdatawould feed the chart the host's PAGE, capping a gantt atpagination.pageSize— a complete schedule becomes a quietly truncated one that still looks like a schedule. Whether a non-grid view may fetch unbounded at all is an open maintainer decision recorded on objectui#7210 (half 2) and escalated on objectui#5560; it is not settled by this card and must not be settled as a side effect of a prop-forwarding tidy-up. The two safe pieces here are the comment and the inert clause.Refs: objectui#7210 (parent observation; halves 2 and 3 open there), objectui#7221 (the filter-dialect half).