demo D110
Diagnostics and devtools in Angular
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 Angular version. A standalone component takes the whole configuration through one config input, surfaces grid events as outputs, and exposes the live grid on a getter for anything the inputs do not cover.
The configuration
import { Component } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { createGrid } from '@toclocoinc/lattice-grid';
import '@toclocoinc/lattice-grid/css';
import { LatticeGridComponent, provideLattice } from '@toclocoinc/lattice-grid/angular';
@Component({
selector: 'app-root',
standalone: true,
imports: [LatticeGridComponent],
template: '<lattice-grid [config]="grid"></lattice-grid>',
})
export class AppComponent {
// 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.
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 },
sort: false, filter: false,
value: {
pure: false, deps: '*',
compute: (deps: any, ctx: any) => {
const diagnostics = ctx?.grid?.diagnostics;
if (!diagnostics) return 'no diagnostics api';
return (globalThis as any).readDiagnostic(ctx?.data?.id, diagnostics);
},
},
},
],
rows: [/* one row per diagnostic reading, each with an id, section and metric */],
};
}
bootstrapApplication(AppComponent, {
providers: [provideLattice({ createGrid })],
});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.