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 compatibility layer exists to take that reason to stay away. It exports a Grid class shaped like the grid API an existing application already calls: 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 an existing application already has.

What the swap covers

Change the import of the old 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 original event names are mapped down to the specific ones, afterEditEnd, afterColumnDrop, afterSort and the rest, so a handler wired to an original 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 the original API 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

  • We Migrated 166 Grids to Lattice Grid. Here's What Broke.

    TOCLOCO moved its own product, DemandFlow, onto Lattice Grid across 166 grids. What it took, what broke in our grid and our own code, and what got better.

  • An editable grid for your pandas DataFrame

    Render a pandas DataFrame as an interactive, editable grid in a Jupyter notebook, then read every edit back in Python with dtypes preserved. The same grid runs in Dash.

  • A grid over DuckDB, in the browser

    Point Lattice Grid at a duckdb-wasm connection and it pushes filter, sort and paging down, and gets whole-dataset stats by pulling the set in or pushing the aggregation to DuckDB.

All posts RSS