demo D13
Two hundred columns
Body cells exist only for the columns in the horizontal window
columnVirtualisationAbove
The configuration
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.13.0/lattice-grid.min.css">
<script src="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.13.0/lattice-grid.min.js"></script>
<div id="grid" style="height: 540px"></div>
<script>
// Two hundred numeric columns, plus a pinned label. Building them by hand
// would be two hundred near-identical lines, so build them in a loop.
const columns = [
{ field: 'label', title: 'Row', layout: { pin: 'start', width: 110 } },
];
for (let c = 1; c <= 200; c++) {
columns.push({ field: `m${String(c).padStart(3, '0')}`, title: `M${c}`, type: 'number', layout: { width: 90 } });
}
const grid = LatticeGrid.createGrid(document.getElementById('grid'), {
rowKey: 'id',
// Above this many columns the body renders only the horizontal window, so a
// row keeps roughly seventeen cells in the DOM rather than two hundred.
columnVirtualisationAbove: 30,
columns,
rows, // 2,000 rows across 200 columns
});
</script>Column virtualisation for grids with hundreds of fields
Column virtualisation, the horizontal counterpart to row virtualisation, means a JavaScript data grid only builds body cells for the columns currently within the scrollable viewport, plus a small margin either side. Reach for this whenever a dataset carries more fields than a screen can show at once, such as an export-grade record with two hundred attributes, and the alternative would mean laying out and painting cells the user cannot see. Lattice Grid controls the margin through columnVirtualisationAbove, which sets the column count beyond which the horizontal window applies; below that threshold the grid renders the full row, since windowing a handful of columns costs more in bookkeeping than it saves.
As the user scrolls horizontally, cells for columns leaving the window are recycled into the columns entering it rather than destroyed and rebuilt, so the DOM node count stays bounded regardless of how many columns the dataset defines. Scrolling, sorting and filtering read from the full column set underneath; only the render layer is windowed, so off-screen columns behave identically to visible ones. Keyboard navigation across the row still visits every column in order, including ones outside the current window, and focus scrolls the target column into view before moving to it, so the feature does not create a gap in tab order at the viewport edge.
How do you render a grid with hundreds of columns without it slowing down?
Virtualise the columns the same way you virtualise rows: build DOM cells only for the columns inside the current horizontal scroll window, recycling them as the user scrolls sideways. Lattice Grid does this automatically once a row’s column count passes columnVirtualisationAbove, keeping cell count bounded independent of how many columns the dataset defines.