Lattice Grid Buy a licence

blog

Swap the import

Building…
Loading a live grid…

A grid is rarely the reason a team rewrites a screen, but it is often the thing in the way. The data is loaded, the columns are defined, the selection and the editing and the export all work, and every one of them is written against one grid’s API. Moving to another grid usually means touching all of those call sites at once, which is why teams stay on a grid long after they would have chosen a different one.

The dhtmlx compatibility layer exists to take that reason to stay away. It exports a Grid class shaped like dhtmlx’s own dhx.Grid: the same constructor call, and the same .data, .selection, .history, .export and .events namespaces, sitting on a real Lattice grid underneath. The grid above is built through it. The code that constructs it, adds and removes rows, reads the selection and writes a sheet is the code a dhtmlx application already has.

What the swap covers

Change the import from dhtmlx’s Grid to the compatibility module and, for the surface most applications actually touch, that is the migration. Column definitions carry across with their header, width, sortable, resizable, hidden and editorType. The .data namespace keeps add, update, remove, parse, load, find, sort, filter and serialize. .selection, .history, .export.csv and .export.xlsx keep their methods. The dhtmlx event names are mapped down to the specific ones, afterEditEnd, afterColumnDrop, afterSort and the rest, so a handler wired to a dhtmlx event fires on the same occasion here.

Where it stops, and what happens there

It is a compatibility surface, not a re-implementation, and the honest thing to say about any such surface is where it ends. A call the wrapper does not map is not a dead end: the real grid is one property away, on .lattice, and everything Lattice Grid can do that dhtmlx never named is reached there directly. So the layer is a way to move an existing screen without a rewrite, and then to reach past it for the capabilities you moved in order to get.

That is the whole proposition. Keep the code you have where the two grids agree, and drop to the grid underneath where they do not.

See it running or read the guide.

Read next

  • The table is the schema

    htmx renders the table on the server; Lattice Grid upgrades it into a live grid in place, columns and rows read straight from the markup, and it survives htmx swaps.

  • The column knows it holds metres

    In most grids a unit is a formatter, and a formatter is a lie that shows the moment someone sorts. Lattice Grid makes a quantity a data type, so the column stays a number.

  • When the grid became the interface

    Grids are sold to developers, so they are built for developers. Why Lattice Grid ships redaction, annotation and presentation tools to every user as standard.

All posts RSS