demo D77
A large tree
Fifty thousand nodes, ten deep, a collapsed branch costing nothing
virtualised tree
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>
const grid = LatticeGrid.createGrid(document.getElementById('grid'), {
rowKey: 'id',
selection: 'multiple',
grandTotalRow: 'bottom',
toolPanel: {
side: 'left',
panels: ['columns', 'filters', 'views', 'quick'],
actions: ['undo', 'redo', 'export', 'restore', 'maximise'],
exportName: 'lattice-demo',
},
tree: { parentKey: 'parentId', label: 'name', title: 'Node' },
columns: [
{ field: 'level', title: 'Depth', type: 'number', filter: { type: 'number' }, layout: { width: 110 } },
{ field: 'region', title: 'Region', filter: { type: 'set' }, layout: { width: 150 } },
{ field: 'devices', title: 'Devices', type: 'number', total: 'sum', layout: { width: 120 } },
{ field: 'charge', title: 'Monthly charge', type: 'number', format: { style: 'currency', currency: 'GBP', decimals: 0 }, total: 'sum', layout: { width: 180 } },
],
rows, // 50,000 nodes, ten levels deep
});
</script>Virtualised tree rendering for large hierarchies
A virtualised tree keeps a JavaScript data grid fast when the hierarchy itself is the size problem, not just the row count. Reach for this with an org chart, a bill of materials, or a file tree running to tens of thousands of nodes and ten or more levels deep, where expanding everything would lay out every descendant whether or not it is on screen. Lattice Grid treats a collapsed branch as a single row for layout purposes: the virtualised tree option means children below a collapsed node are never measured, positioned or painted, so collapsing a subtree of any size is a constant-time operation rather than one proportional to what it hides.
At fifty thousand nodes, ten levels deep, the grid still only builds DOM rows for the visible window plus a small overscan margin, exactly as it does for a flat list; depth changes how indentation is computed per row, not how many rows exist in memory. Expand and collapse toggle a node’s descendants without re-deriving the whole tree, so opening one branch near the bottom of a large hierarchy does not force a recompute of siblings elsewhere. Keyboard users move through the tree with the same roving tab stop as a flat grid, and each row announces its depth and expanded state through aria-level and aria-expanded.
How do you keep a tree grid fast with tens of thousands of nodes?
Virtualise on the rendered row list, not the underlying tree: collapsed branches contribute one row to layout regardless of how many descendants they contain, and only the currently visible rows get DOM nodes. Lattice Grid applies this by default, so expanding or collapsing a branch is cheap independent of hierarchy depth or the size of the subtree involved.