Capítulo 19 de 54
column objects (not to be confused with column definitions, the config you write) hold state-derived metadata but aren't meant to render markup directly — for actual rendering, use the header/cell objects that reference them, not the column object itself.
cell.column, header.column, or via table APIs: table.getColumn('id') (single, by id), table.getAllColumns() (all), plus feature-specific variants (getAllFlatColumns, getAllLeafColumns, getCenterLeafColumns, getStartVisibleLeafColumns, ...) that come into play with column visibility/pinning.column.id is always defined (explicitly, or derived from accessorKey/header — see Column Definitions Guide) and unique.column.columnDef is a live reference back to the original column definition object used to create it.column.columns (child columns, for a group column), column.depth (header-row index the group belongs to), column.parent (parent column, undefined for top-level columns).column objects to render headers/cells — that's what header/cell objects are for. Do reach for column objects when building something like a column-visibility toggle menu, where you just need to list/iterate columns.const column = table.getColumn('firstName')
const allColumns = table.getAllColumns()
// a visibility-toggle menu is a legitimate direct use of column objects:
allColumns.map((col) => (
<label key={col.id}>
<input type="checkbox" checked={col.getIsVisible()} onChange={col.getToggleVisibilityHandler()} />
{col.id}
</label>
))
column objects directly — a settings/visibility UI, as opposed to the table body itself.header/cell objects, not column objects — columns describe structure/state, not markup.table.getColumn(id) for a single lookup beats filtering getAllColumns() yourself.column.parent/column.columns/column.depth only matter once you use grouped (columnHelper.group) column definitions.column's id and columnDef are actually set up.