demo D110
Diagnostics and devtools
Frame times, stage rebuilds, store layout, warnings
grid.diagnostics
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"></div>
<script>
// autoHeight lets the grid take the height of its rows rather than the height
// of its container. This grid reports on itself: the Reading column is computed
// from the grid.diagnostics of the very grid displaying it.
const grid = LatticeGrid.createGrid(document.getElementById('grid'), {
autoHeight: true,
columns: [
{ field: 'section', title: 'Section', layout: { width: 170 } },
{ field: 'metric', title: 'Metric', layout: { width: 200 } },
{
id: 'reading',
title: 'Reading',
layout: { flex: 1, min: 260 },
// Sorting or filtering an impure computed column makes the grid warn
// about exactly that.
sort: false,
filter: false,
// pure: false because the reading depends on the grid rather than on the
// row, so it must never be materialised into the store as though it were data.
value: {
pure: false,
deps: '*',
compute: (deps, ctx) => {
const diagnostics = ctx?.grid?.diagnostics;
if (!diagnostics) return 'no diagnostics api';
// Read one line off the live diagnostics api, keyed by the row id.
return readDiagnostic(ctx?.data?.id, diagnostics);
},
},
},
],
rows, // one row per diagnostic reading, each with an id, section and metric
});
</script>Watching a JavaScript data grid’s own frame budget
Diagnostics is the introspection layer that shows what the grid is doing to itself: frame times per render pass, which internal stages rebuilt on the last update, the current store layout, and any warnings raised about its own configuration. A developer reaches for it while tuning a large or densely configured grid, when a scroll stutters, a column change triggers more work than expected, or a warning about a missing row key needs a source. Lattice Grid exposes this through grid.diagnostics, which surfaces the same internal counters the grid uses to decide whether to skip a rebuild, so the numbers on screen match what the render loop actually measured rather than an estimate taken from outside. Frame times are broken down by stage, so a slow update traces to layout, row virtualisation, or paint rather than one undifferentiated delay. Store layout reporting shows how rows and columns are currently indexed, which explains why one filter is cheap and another forces a fuller rebuild. Warnings surface at the point the grid notices a problem, such as a duplicate row id, rather than showing up later as an unrelated rendering issue. The demo runs this panel live against the grid beside it, so every scroll, sort, and edit updates the same counters a developer would otherwise instrument by hand.
How do you profile a JavaScript data grid’s render performance?
Read grid.diagnostics for per-stage frame times and a record of which stages rebuilt on the last update, rather than timing the DOM externally. Lattice Grid tracks these internally as part of deciding what to skip on each render, so the reported numbers reflect the grid’s own scheduling decisions, including store layout and any configuration warnings, not an estimate taken from outside the render loop.