demo D110
Diagnostics and devtools in ESM
Frame times, stage rebuilds, store layout, warnings
grid.diagnostics
This opens a devtools panel showing frame times, which stages rebuilt, the store layout and any warnings. It answers why a grid stuttered or a filter took too long directly, so tuning is measurement rather than guesswork.
This is the ES module version. The grid is imported straight from a CDN as a module, the same configuration as the vanilla tab without a global script tag, so it drops into any bundler or a bare module script.
The configuration
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.71.0/lattice-grid.min.css">
<div id="grid"></div>
<script type="module">
import { createGrid } from 'https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.71.0/lattice-grid.esm.min.js';
// 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 = 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>See why a data grid feels slow, and what to fix
When a grid stutters on scroll or a filter takes longer than it should, the usual next step is guesswork with a profiler. Lattice Grid answers the question directly: a diagnostics panel shows where each update spent its time, which parts of the grid actually redrew, and how the data is currently laid out, so a slow moment traces to a cause you can act on rather than a delay you cannot place. It also flags the mistakes that quietly cost performance, such as two rows sharing the same id or a missing row key, at the point the grid notices them rather than later as an unrelated glitch. Everything on screen is read from the grid’s own figures through grid.diagnostics, so the numbers match what the grid actually did on the last update rather than an estimate taken from outside. The panel below runs live against the grid beside it, so every scroll, sort and edit updates the same figures you would otherwise have to instrument by hand, and when you need to hand a problem to someone else, grid.diagnostics.bundle() gathers it all into one object that carries no row, cell or column values, so it can go to support without anyone reading it first.
How do you find out why a JavaScript data grid is slow?
Open grid.diagnostics for a breakdown of where each update spent its time and which parts of the grid redrew, instead of timing the page from outside. Lattice Grid keeps these figures as it runs, so they reflect what the grid actually did rather than an estimate, and it surfaces configuration problems such as duplicate row ids or a missing row key at the point they occur, so the cause of a stutter is named rather than hunted for.