Get going in two minutes
Most data grids will get you to a working table reasonably quickly. That is not really the question.
The question is what you agreed to on the way there. A package install, a bundler, a set of peer dependencies that have to agree with each other, and a dependency tree that is now yours to keep patched for as long as the feature lives.
Lattice Grid’s normal path has none of that in it. The grid above is the whole of a bare configuration. One object, one key.
What the configuration actually is
Two files go into the page, a script and a stylesheet. Neither brings anything else with it, because the grid has no runtime dependencies: no date library, no virtualisation library, no icon font.
Then a div with a height, because a grid that virtualises has to know how tall it is, and then this:
createGrid(document.getElementById('orders'), {
columns: [
{ field: 'reference', title: 'Reference' },
{ field: 'supplier', title: 'Supplier' },
{ field: 'status', title: 'Status' },
{ field: 'quantity', title: 'Quantity', type: 'number' },
{ field: 'value', title: 'Value', type: 'number' },
],
});
That is the configuration above, copied out rather than paraphrased. Five columns, two of which say what kind of number they hold. Nothing else.
What arrived without being asked for
Click a column heading and it sorts. Click again and it reverses. Open the
filter on any column and it is there, already the right kind: a text filter on
Reference, Supplier and Status, and a numeric range filter on Quantity and
Value, because those two said type: 'number' and a type carries its own
filter. Drag the edge of a heading and the column resizes. Drag the heading
itself and the column moves.
We checked this by building that exact configuration through the headless grid and reading the columns back. All five come out with sorting enabled, filtering enabled, resizable true and movable true, and none of those four words appears in the configuration above.
The grid is also one tab stop rather than five thousand, and moves the focused cell with the arrow keys, which is the difference between a table a keyboard user can use and a table a keyboard user gives up on. That one is worth watching rather than reading about, and there is a demo that shows the keys as they are pressed.
The two type: 'number' declarations are the one thing in that snippet doing
real work, and they are worth being honest about. Leave them off and both columns
are text: they will still sort, and they will sort like text. A type is not a
label, and this is the smallest possible demonstration of why.
Where it goes from there
Everything else is additive. rowKey gives rows an identity, which is what
selection persistence, undo and live updates are built on. toolPanel puts the
icon rail down the side. columnDefaults says a thing once for every column.
total: 'sum' puts a footer under a column and keeps it correct when a filter is
applied. None of it is required to get to the grid above, and none of it is a
different grid: it is the same object with more keys in it.
It behaves identically in React, Vue, Svelte or a plain HTML page, because it is vanilla JavaScript and does not know which one it is in. Adapters for the first three exist if you would rather write a component than call a function, and there is a web component if you would rather write a tag.
Development on localhost is free and needs no key at all, so the two minutes above is genuinely the whole cost of finding out whether this suits you. Point it at your own awkward data, the set with the nulls in the column somebody promised would never have nulls, and see what it does.
Copy the snippet from the docs or try it with your own columns in the playground.