Observation found while tracing objectui#5415's cell-clamping path. Not fixed there — different class, and it is dead code rather than a user-visible defect.
What
packages/plugin-grid/src/ObjectGrid.tsx:1733, in the ListColumn-object branch of the column builder:
...(col.wrap!==undefined&&{wrap: col.wrap}),The key is copied onto the column object handed to DataTable. packages/components/src/renderers/complex/data-table.tsx never reads a column-level wrap.
Evidence, with the counter-probe
Read-counts in data-table.tsx for the sibling keys ObjectGrid forwards on the same lines:
| forwarded key | occurrences in data-table.tsx |
|---|
fitContent | 7 |
align | 5 |
pinned | 7 |
wrap (column-level) | 0 |
The raw count for the string wrap in that file is 12, but every one is flex-wrap, whitespace-nowrap, or a variable named wrapper — none is a read of col.wrap. The sibling counts are the counter-probe: the same search style does find the keys that are genuinely consumed, so the zero is a real zero and not a mis-aimed grep.
wrap is also absent from packages/types/src/views.ts, so it is read off an untyped col — tsc cannot see the dangling end.
Why it is worth a card
This is the "renderer forwards it, nothing consumes it" shape the repo already tracks. Its cost is concrete: wrap is the obvious key to reach for when someone wants a grid cell to show more than one line, and it silently does nothing — so the next person to need that behaviour either re-derives it somewhere else or concludes the grid cannot do it.
Two honest resolutions, both cheap:
- implement it —
wrap: true drops the truncate on that column's cell wrapper (the wrapper is data-table.tsx:2275), which also gives the grid a declared escape hatch for long-text columns; or - remove the forward — delete the line in
ObjectGrid.tsx so no author is invited to declare a key with no effect.
Which one is right depends on whether a per-column wrap is wanted at all; that overlaps objectui#5415's open question about how grid cells should treat long text, so they may want deciding together.
Observation found while tracing objectui#5415's cell-clamping path. Not fixed there — different class, and it is dead code rather than a user-visible defect.
What
packages/plugin-grid/src/ObjectGrid.tsx:1733, in the ListColumn-object branch of the column builder:The key is copied onto the column object handed to
DataTable.packages/components/src/renderers/complex/data-table.tsxnever reads a column-levelwrap.Evidence, with the counter-probe
Read-counts in
data-table.tsxfor the sibling keysObjectGridforwards on the same lines:data-table.tsxfitContentalignpinnedwrap(column-level)The raw count for the string
wrapin that file is 12, but every one isflex-wrap,whitespace-nowrap, or a variable namedwrapper— none is a read ofcol.wrap. The sibling counts are the counter-probe: the same search style does find the keys that are genuinely consumed, so the zero is a real zero and not a mis-aimed grep.wrapis also absent frompackages/types/src/views.ts, so it is read off an untypedcol—tsccannot see the dangling end.Why it is worth a card
This is the "renderer forwards it, nothing consumes it" shape the repo already tracks. Its cost is concrete:
wrapis the obvious key to reach for when someone wants a grid cell to show more than one line, and it silently does nothing — so the next person to need that behaviour either re-derives it somewhere else or concludes the grid cannot do it.Two honest resolutions, both cheap:
wrap: truedrops thetruncateon that column's cell wrapper (the wrapper isdata-table.tsx:2275), which also gives the grid a declared escape hatch for long-text columns; orObjectGrid.tsxso no author is invited to declare a key with no effect.Which one is right depends on whether a per-column wrap is wanted at all; that overlaps objectui#5415's open question about how grid cells should treat long text, so they may want deciding together.