demo D160
Coming from another grid API in Angular
An existing grid API, unchanged, on a Lattice grid underneath
new Grid(el, { columns, data })
This runs an existing grid API unchanged, the same constructor and namespaces, on a Lattice grid underneath. It lets a project already written against that API move over without rewriting its grid code, keeping the calls it already makes.
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, ViewChild, ElementRef, AfterViewInit, OnDestroy } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
// The same bare specifier every other module sample imports by name; a
// bundler resolves it from your package.json, and a page with no build
// step needs an import map naming the file - the one this site's own
// pages carry (see Base.astro).
import { Grid } from '@toclocoinc/lattice-grid/modules/dhtmlx-compat';
@Component({
selector: 'app-root',
standalone: true,
template: '<div #el style="height:540px"></div>',
})
export class AppComponent implements AfterViewInit, OnDestroy {
@ViewChild('el') elRef!: ElementRef<HTMLElement>;
private grid: any;
ngAfterViewInit() {
// The same constructor and the same .data / .selection / .history /
// .export / .events namespaces as the grid API an existing application already calls.
this.grid = new Grid(this.elRef.nativeElement, {
columns: [
{ id: 'invoice', header: [{ text: 'Invoice' }], width: 130 },
{ id: 'supplier', header: [{ text: 'Supplier' }], width: 210, sortable: true },
{ id: 'amount', header: [{ text: 'Amount' }], type: 'number', width: 140, sortable: true },
],
data: [/* your data */],
});
}
ngOnDestroy() {
this.grid?.destructor();
}
}
bootstrapApplication(AppComponent);Running existing grid code on Lattice Grid
The compatibility module 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. Swapping the import is, for that surface, the whole migration. The calling code that adds, updates and removes rows, reads the selection, undoes an edit or writes a sheet does not change.
What is covered is the part most applications actually touch: column definitions (header, width, sortable, resizable, hidden, editorType and the rest), the .data operations from add and update through parse, load, sort, filter and serialize, then .selection, .history, .export.csv and .export.xlsx, and the original event names down to afterEditEnd and afterColumnDrop. It is a compatibility surface rather than a re-implementation, so a call it does not map is not a dead end: the real grid is one property away, on .lattice, and anything the wrapper does not cover is reached there directly.
How do you move an existing grid integration to Lattice Grid?
Change the import of the old Grid to @toclocoinc/lattice-grid/modules/dhtmlx-compat, keep the constructor and the namespace calls as they are, and the grid renders on Lattice Grid instead. Columns, data operations, selection, history, export and the event names are mapped across, so the surface most application code depends on keeps working without a rewrite, and the parts outside that surface are reached through the underlying grid rather than blocking the move.