DEV Community: Tony Goodchild

Every data grid claims to handle live data.

Tony Goodchild — Tue, 13 Oct 2026 20:03:00 +0000

Every data grid claims to handle live data. We wanted a workload that would not let us hand-wave, so we compiled Doom to WebAssembly and made a grid its screen. You can play it here: https://toclocoinc.github.io/lattice-grid-demo-doom/ (arrows move, F or Shift fires, Space uses). The code is on GitHub: https://github.com/toclocoinc/lattice-grid-demo-doom

This is the story of how it works, what we measured and what changed in the grid because of it.

The setup

The engine is doomgeneric, a port of the original Doom source whose only job is to hand each rendered frame to the host as a raw pixel buffer. It is compiled with Emscripten and runs Freedoom's level data, which is freely redistributable. There is no SDL, no audio and no canvas in the page.

Each frame arrives as 320 by 200 pixels. The page keeps the previous frame, diffs the new one against it, and works out which rows changed. Then it pushes those rows into a Lattice Grid through the ordinary row-update call, grid.rows.apply, the same call an application uses when a price ticks or a status flips. The grid does not know it is drawing a game.

Pixels as cells, then rows as gradients

The first version was the purest one: one grid cell per pixel, each cell's background colour coming from its value through a formatting rule. At 80 by 50 that is 4,000 cells, and it plays at around 33 frames a second. It is also the version that made us measure properly.

Timing a rows.apply call against the next animation frame reported about 17 milliseconds whatever we threw at it. That number was the cost of enqueueing the update. The grid, like any serious renderer, defers its DOM writes to its own frame tick, so the honest measurement is the time from the call until the changed cell's computed background is actually on screen. We built a small harness for exactly that, and it became the yardstick for everything that followed.

At 160 by 100 and above, the limit is the browser itself: restyling and painting ten thousand changed elements a frame is more than any DOM can do at game speed. So the shipped demo takes a different shape. The grid has one column and 200 rows. Each row's cell carries its line of pixels as a single hard-stop CSS gradient, with runs of the same colour merged, still applied through the formatting rule, still delivered through rows.apply. A frame that changes 35,000 pixels becomes about 170 row writes. Native 320 by 200 runs at 30 to 60 frames a second on a desktop Chrome, and the engine's own 35 frame cap is now the limiter.

The page keeps both ideas visible. The resolution switch offers 160 by 100 and 80 by 50, and an automatic fallback drops to 160 by 100 if a machine cannot hold 30 frames a second during the first seconds of play.

What changed in the grid

A demo like this is only worth doing if the product gets better. Two things did, and both shipped this week to every user.

Conditional formatting rules now cost the same as unstyled cells on a bulk update. Put a rule on every cell of a live board and 4,000 styled cells still update in one frame.

A partial update now costs only the rows and cells it touched. Attributes, classes, text nodes and cell positions are written only when their value actually moves, and the overflow-title measurement runs only for a cell whose text or width changed. On an 80 by 50 grid, 4,000 changed styled cells reach the screen in about 49 milliseconds, and 900 in about 33, measured by the harness above.

Neither change needs an option. A grid fed by a websocket, a polling loop or a trading feed simply does less work per tick.

Try it

Play it in the browser: https://toclocoinc.github.io/lattice-grid-demo-doom/

Read the pipeline, it is under 200 lines: https://github.com/toclocoinc/lattice-grid-demo-doom

Chart a derived grid: source and derived data in one live chart

Tony Goodchild — Thu, 08 Oct 2026 11:05:00 +0000

Chart a derived grid: source and derived data in one live chart

A revenue-by-region chart next to an orders table is two things to keep in step. Filter the table and the chart either follows or it doesn't, and the difference is usually a line of sync code nobody wrote.

The three usual fixes all leak:

A second query. Two round trips doing the same arithmetic, two places for the business logic to drift apart, and a second failure mode on a panel that only summarises the first.
A copied array. orders reduced into a summary once, on load. Nothing tells the copy when the original changes.
A spreadsheet export. Correct for exactly the moment it was taken.

Lattice Grid has a different primitive: a derived grid.

What a derived grid is

A derived grid is a grid whose source is another grid rather than a dataset. You don't give it rows; you give it a recipe:

Which of the parent's rows to read (follow): filtered (whatever the parent's filters leave), selected (only the ticked rows), grouped (one row per group of the user's own grouping) or all.
What to do with them: group and aggregate (groupBy + select), bucket dates (bucket), join a related grid, sort, keep the top N.

It holds no rows of its own. When the parent's rows change, whether from a filter, an edit or new data arriving, it re-runs the recipe over the rows the parent already has in memory.

Why that works

There is only one copy of the data. The summary is a function of the source, not a second dataset, so it cannot drift.
No second round trip. The rows already arrived once; the derivation is in-memory arithmetic over them.
The rule lives in one place. "Revenue by region" is declared once, next to the grid it summarises.
It is still a grid. Sorting, filtering, export, KPI tiles and charts all work on it unchanged, and they all inherit its liveness. A chart only ever reads a grid, so a chart over a derived grid is live by construction.
It is cheap by default. Re-derivation runs once per idle frame (refresh: 'idle'), so a hundred edits in one burst cost one recalculation.

A chart that follows a filter

import { createGrid } from '@toclocoinc/lattice-grid';  
import { createChart } from '@toclocoinc/lattice-grid/modules/charts';

const book = createGrid(document.querySelector('#orders'), {  
  rowKey: 'id',  
  columns: [  
    { field: 'id', title: 'Order' },  
    { field: 'region', title: 'Region', filter: { type: 'set' } },  
    { field: 'date', title: 'Date', type: 'dateString' },  
    { field: 'amount', title: 'Amount', type: 'number' },  
  ],  
  rows: orders, // sixteen orders across two months and three regions  
});

// A second grid, built from the first.  
const byRegion = createGrid(document.querySelector('#by-region'), {  
  columns: [  
    { field: 'region', title: 'Region' },  
    { field: 'revenue', title: 'Revenue', type: 'number' },  
  ],  
  source: {  
    mode: 'derived',  
    from: book,  
    follow: 'filtered',  
    refresh: 'live',  
    groupBy: 'region',  
    select: { revenue: { of: 'amount', fn: 'sum' } },  
    sort: [{ col: 'revenue', dir: 'desc' }],  
  },  
});

// The chart reads byRegion, not a copy of its rows.  
createChart({ grid: byRegion, container: document.querySelector('#chart'), type: 'bar', x: 'region', y: 'revenue' });

follow: 'filtered' means the derived grid reads whatever the orders grid's filters leave. Filter the orders to EMEA and Americas, and byRegion drops to two rows: APAC is gone from the grid and from the chart in the same redraw, with no second call behind either.

The other follow modes: selected reads only the ticked rows, grouped reads one row per group of the user's own grouping, and all ignores the parent's filter (for an exceptions list that shouldn't shrink with the table).

Source and derived data in one chart

A chart reads one grid. To overlay the raw orders and a derived monthly total, build a third grid whose from is a union of the two. Each source gets a label and a map that reshapes its rows, and every combined row keeps a __source field saying where it came from.

const monthlyTotal = createGrid(document.querySelector('#monthly'), {  
  columns: [  
    { field: 'date', title: 'Month', type: 'dateString' },  
    { field: 'revenue', title: 'Revenue', type: 'number' },  
  ],  
  source: {  
    mode: 'derived', from: book, follow: 'filtered', refresh: 'live',  
    groupBy: 'date', bucket: { of: 'date', by: 'month' },  
    select: { revenue: { of: 'amount', fn: 'sum' } },  
  },  
});

const overlay = createGrid(document.querySelector('#overlay'), {  
  columns: [  
    { field: '__source', title: 'Feed' },  
    { field: 'date', title: 'Date' },  
    { field: 'daily', title: 'Daily' },  
    { field: 'monthly', title: 'Monthly' },  
  ],  
  source: {  
    mode: 'derived', refresh: 'live',  
    from: [  
      { grid: book, label: 'orders', map: (r) => ({ date: r.date, daily: r.amount }) },  
      { grid: monthlyTotal, label: 'monthly total', map: (r) => ({ date: r.date, monthly: r.revenue }) },  
    ],  
    sort: [{ col: 'date', dir: 'asc' }],  
  },  
});

createChart({  
  grid: overlay,  
  container: document.querySelector('#overlay-chart'),  
  type: 'combo',  
  x: 'date',  
  measures: [  
    { col: 'daily', fn: 'sum', type: 'bar', axis: 'left', title: 'Daily orders' },  
    { col: 'monthly', fn: 'sum', type: 'line', axis: 'right', title: 'Monthly total' },  
  ],  
});

The map step is what makes the overlay work: the two sources don't share a column (one has amount, the other revenue), so each map renames its value into a column of its own. That lets one chart draw daily orders as bars and the monthly total as a line on its own right-hand axis, since a month of orders runs far larger than any single order.

With the sixteen sample orders, overlay holds eighteen rows: sixteen tagged orders and two tagged monthly total (January 3,725, February 3,090). Those two points are read from the same rows as the bars, not typed in separately. Filter the orders and monthlyTotal re-derives first, overlay next, and the chart redraws last, all on one frame.

When not to reach for one

A derived grid re-derives on an idle frame by default (refresh: 'idle'), so a hundred edits in one event cost one derivation. refresh: 'live' re-derives on every change, which suits a demo and wastes effort on a feed updating faster than anyone can read. refresh: 'manual' never re-derives on its own, for a panel someone refreshes with a button.

Both demos run live, with the full code, here: Chart a Derived Grid.

We Migrated 166 Grids off AG Grid. Here's What Broke.

Tony Goodchild — Fri, 02 Oct 2026 12:10:48 +0000

We moved DemandFlow, our own B2B platform, off AG Grid and onto Lattice Grid, the grid we also make. That makes us an interested party, so weigh the good results accordingly. It also means every defect below was found by us, in our own product, before a customer could hit it.

Every grid fix it produced shipped in Lattice Grid 1.56 and 1.57; the current release is 1.85.

The result
All 166 grids moved in about a week, and three libraries left the codebase. That week covered building the conversion layer, converting each grid and re-testing each one afterwards.

AG Grid is gone from all 166 grids.
FullCalendar, which ran the scheduling screens, is replaced by Lattice Grid’s calendar module.
DHTMLX Kanban, which ran the boards, is replaced by Lattice Grid’s kanban module, reading the same data as the grids.
State handling for sort, filter, grouping and column layout went from about 700 lines to about 190, built on Lattice Grid’s state object and state.apply().
Why a week was enough
Every grid in DemandFlow was already created through one house function, df_lattice_create_grid. It took the AG Grid options a screen already had and translated them into a Lattice Grid configuration. That turned 166 separate integrations into one conversion function and 166 call sites.

Around it sat a small set of shared helpers: one that builds context menus, generators that turn a field list into column definitions, and a few more for jobs every screen repeats. Converting a helper converted every screen that used it. Most per-grid work came down to checking the result, not rewriting the screen.

It also let us get basic grids running quickly, then move each helper across as its own small piece of work instead of one large cut-over. The scheduling screens show how far that goes: moving them off FullCalendar took about an hour.

If you are planning a move like this, copy that part first. Put every grid behind your own helpers while you are still on the old library, and the migration becomes a change to the helpers.

What broke in our grid
Converting 166 real grids put configurations in front of Lattice Grid that our own tests never had reason to write: options carried over verbatim from AG Grid, values typed from memory, and edge cases that only appear with real users. Most of what surfaced followed one pattern, and it is the lesson worth keeping: rejected input should never become state. A grid that refuses a bad value but quietly keeps it is worse than one that never checked, because the host believes it is protected.

Four examples show the pattern:

A sort on a column that did not exist was rejected for sorting but still written into saved state, so the rejection repeated on every reload. It is now dropped before it is stored.
An unknown filter operator was accepted and matched every row, while the filter panel showed as active. It is now refused, and the same check covers relative-date tokens.
An unrecognised column key or column type was silently ignored. The grid now warns once, naming the key, the column and, for types, what it fell back to.
The state:changed event fired for only some state changes, so auto-save built on it missed a user’s own sorts and column moves. It now fires once per change, whether from a gesture or an API call.
The rejected-input cases now print a warning naming what was rejected and why, listed in the warnings reference. The full list of fixes, including smaller ones, is in the changelog for 1.56 and 1.57.

Those warnings turned out to be the part of the migration that paid off fastest: “the warning messages are the best I have seen in a grid library.”

The migration also drove three additions: checkboxOnly, so a click outside the checkbox column no longer selects the row; defaults(), for house-wide settings applied once instead of on 166 call sites; and documentation of which features run headlessly with no DOM.

What broke in our own code
A conversion is also an audit of the code being converted. One screen’s AG Grid options defined getRowStyle twice. A JavaScript object literal keeps only the last definition of a repeated key, so the row shading tied to a ranking field never ran in production. Nobody noticed, because a grid without shading does not look broken; it looks plain.

The lesson is to read every key before you carry it across. A mechanical migration through a shared seam is fast precisely because it trusts the old configuration, and that same trust copies old mistakes forward. Treat the source configuration as something to check, not as ground truth.

If you are considering the same move
This is one application’s experience, not a benchmark; we will not publish one without a runnable public harness behind it. Three places to start:

The AG Grid migration guide maps AG Grid options, events and API calls to their Lattice Grid equivalents, with one real configuration converted line by line.
The AG Grid alternative page covers licensing, feature coverage and where each grid is ahead.
The warnings reference lists the warning you will see for each problem described above, and what it means.
If anything else turns up from this migration, we will add it here.

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 3: edit in place

Tony Goodchild — Wed, 30 Sep 2026 14:08:01 +0000

This is the dev.to edition of a tutorial that lives, with a live copy of the finished grid you can try, at latticegrid.dev/tutorials/crud-dynamodb-part-3. Part 1 built the table, the Lambda function and a page that reads from it; Part 2 added a product through the grid's form and deleted one from its menu.

Part 2 gave the page add and delete. This part makes the cells themselves editable, with each change patched to DynamoDB the moment it is committed and put back if the server refuses it. It also adds a full-screen button and moves the row form out of its drawer into a panel that is part of the page.

Source: the part-3 folder of toclocoinc/lattice-tutorial-crud-dynamodb (Download ZIP). Needs Lattice Grid 1.76.0 or later.

Step 1: the function learns PATCH

On the function's Code tab, replace index.mjs with lambda/index.mjs from the download and choose Deploy.

PATCH takes ?sku= and a JSON body holding only the fields that changed. It builds a DynamoDB update expression from the fields it allows (name, category, quantity, price), stamps updated, and refuses to update a product that does not exist, so a PATCH can never create one by accident. It answers with the whole product as stored.

The allow-list matters. A PATCH endpoint is a public door in this tutorial, and without the list a caller could set any attribute on any product. With it, the function only ever changes the four fields the page edits.

Step 2: allow PATCH through the URL

Configuration, Function URL, Edit. Under the CORS settings add PATCH to Allow methods, keeping GET, POST and DELETE and the content-type header. Save. The IAM policy from part 2 already includes UpdateItem, so nothing changes there.

Step 3: the page

Paste your Function URL into web/index.html as before and open it.

Editable cells. Four columns now carry edit: true. Double-click a quantity, type a new number, press Enter. The cell shows the new value at once, and the grid calls the commit hook you gave it:

edit: {
  commit: (write) => api('PATCH', '?sku=' + encodeURIComponent(write.key), { [write.colId]: write.value }),
},

write names the row's key, the column and the new value, and the promise you return settles the write: resolve and the cell stays, reject and the grid puts the old value back and fires cell:reverted, which the status line reports. That is optimistic write-back: the user never waits for the network, and a refusal is visible rather than silent.

Try it against the rules: clear a name and press Enter. The function answers 400, the cell reverts, and the status line says why.

Full screen. The button calls grid.maximise.toggle(). The grid fills the window, remembering where it came from and its scroll position, and the same button or Escape puts it back. The grid's own rail offers the same action if you turn the tool panel on; a button is the shorter path for this page.

The form in a panel. The row form has two new lines:

rowForm: {
  container: '#form',
  trigger: false,
  ...
},

With a container, the form renders inside that element instead of over the grid as a drawer. trigger: false takes double-click away from the form, because the cells now want it; the menu gains an Edit in form item that calls grid.form.open(p.key) instead. Right-click a row, choose it, and the row appears in the side panel with the same fields as part 2's form. Save goes through the same commit hook as a cell edit, one call per changed field, so nothing about persistence changed when the form moved. Add product opens the same panel over an empty record, and create handles it as in part 2.

That double-click decision is worth making on purpose in any page that has both. Left to the defaults, the form opens on double-click and the cell never enters edit mode, which reads as "editing does not work".

Step 4: check the table

Change a price, then look at the item in Explore table items. The price and the updated date have moved. Change it again in the console instead and reload the page; the grid shows the console's value, because the page has no copy of the truth beyond what the function returns.

What you have

A grid that reads, adds, edits and deletes against your own table, with every change confirmed by the server and every refusal shown. The page is under a hundred lines of script, and the parts that would take a week to build by hand, the form, the menu, the optimistic edit with revert, the full-screen mode, came from the grid.

Where to go next

Two things this series left out on purpose. The Function URL has no authentication, so anyone with the URL can change your products; the next step for a real application is an authorizer in front of it, and the grid does not care which. And the function returns every product on every load, which is right at sixty rows and wrong at sixty thousand; the grid's pushdown sources move filtering, sorting and paging into the function so the browser only asks for what it shows. Both are covered in the guides.

Cleaning up

As in part 1: delete the function, the table and the role.

Read the full source, including lambda/index.mjs and web/index.html, on the public repository, or grab it as a ZIP download and skip the cloning.

Lattice Grid is a JavaScript data grid with charts, dashboards and server-side pushdown, free to develop with on localhost. Inline editing with optimistic write-back, the row form and full-screen mode are part of the core grid: latticegrid.dev.

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 2: add and delete

Tony Goodchild — Wed, 30 Sep 2026 11:35:49 +0000

This is the dev.to edition of a tutorial that lives, with a live copy of the finished grid you can try, at latticegrid.dev/tutorials/crud-dynamodb-part-2. Part 1 built the table, the Lambda function and a page that reads from it.

Part 1 ended with a page that reads products from your own DynamoDB table through a Lambda function. This part adds the two verbs that make it an application: adding a product through the grid's built-in form, and deleting one from the right-click menu. Both land in DynamoDB before the page moves on.

Everything from part 1 carries over. You will change the function's code, widen its permissions and its URL settings, and swap the page.

Source: the part-2 folder of toclocoinc/lattice-tutorial-crud-dynamodb (Download ZIP). This part needs Lattice Grid 1.76.0 or later, which is the version the page loads.

Step 1: teach the function two more verbs

Open Lambda, then products-read, then the Code tab. Replace the contents of index.mjs with lambda/index.mjs from the download and choose Deploy.

The function now looks at the request's method:

GET returns every product, as before.
POST takes a product as JSON, gives it a sku if the page did not, stamps updated with today's date, and writes it with a condition that refuses to overwrite an existing sku. It answers with the product as stored.
DELETE takes ?sku= and removes that product.

The condition on the write is the one line worth pausing on. Without it, two people adding a product with the same sku would silently overwrite each other. With it, the second one gets a clear "already exists" answer that the page can show.

Step 2: allow the new verbs through the URL

The Function URL's CORS setting from part 1 allows every origin but only the GET method, so the browser would refuse to send a POST or a DELETE.

On the function's Configuration tab, choose Function URL, then Edit.
Under Configure cross-origin resource sharing (CORS), set Allow methods to GET, POST and DELETE, and Allow headers to content-type. The page sends that header with the JSON body of a POST.
Save.

Step 3: give the function the permission it needs, and no more

Part 1 attached AmazonDynamoDBReadOnlyAccess, which is enough to read and nothing else. The function now writes, so it needs PutItem and DeleteItem, and the tidy way to grant them is a policy that names this one table.

On the Configuration tab, choose Permissions, then click the role name under Execution role. IAM opens.
Under Permissions policies, tick AmazonDynamoDBReadOnlyAccess and choose Remove. Confirm.
Choose Add permissions. This is the same menu part 1 used to attach the read-only policy; this time choose Create inline policy instead of Attach policies. Switch the editor to JSON and paste iam/products-policy.json from the download. Replace REGION with your region (eu-west-2 for London) and ACCOUNT_ID with the twelve-digit account id shown at the top right of the console.
Choose Next, name it products-table, and Create policy.

The policy allows scan, get, put, update and delete on the Products table and nothing on any other table. Update is not used yet; part 3 needs it, and it saves a return trip to IAM.

Step 4: the page

Open web/index.html from the download and paste your Function URL into the same line as in part 1. Open the file in a browser.

Three things are new.

Add product opens the grid's built-in form for a new row. Fill in a name, category, quantity and price, and choose Save. The form validates the fields the way the grid's own editors do, then calls the create hook you gave it:

rowForm: {
  fields: [
    { field: 'name', label: 'Product' },
    { field: 'category', label: 'Category' },
    { field: 'quantity', label: 'In stock' },
    { field: 'price', label: 'Price' },
  ],
  create: (values) => api('POST', '', values),
},

create posts the values to the function and returns what comes back: the product as DynamoDB stored it, with the sku the server assigned. The grid adds that row, scrolls to it and selects it. If the function refuses, the form stays open with your values and a retry, and the status line shows the server's reason.

Right-click a row and the menu has the grid's own items, then a Delete for that product:

contextMenu: (p, defaults) => [
  ...defaults,
  { separator: true },
  {
    name: 'Delete ' + p.data.name,
    action: async () => {
      if (!confirm('Delete ' + p.data.name + '?')) return;
      await api('DELETE', '?sku=' + encodeURIComponent(p.key));
      grid.rows.apply({ remove: [p.key] });
    },
  },
],

p describes the cell that was clicked: p.key is the row's key, the sku, and p.data is your product object. The action deletes on the server first and only then removes the row from the grid, so a failed delete leaves the row where it was.

The api helper is eight lines that wrap fetch, set the JSON header when there is a body, and turn a non-2xx answer into an error carrying the function's message. Every call in the page goes through it.

Step 5: check the table

Add a product, then open DynamoDB, Tables, Products, Explore table items. The new product is there with the sku the function chose. Delete it from the page and refresh the console; it is gone.

What you have

A page that reads, adds and deletes against your own table, with every write happening on the server before the page reflects it. The grid supplied the form and the menu; you supplied two verbs and a policy.

Part 3: edit in place. Cells become editable and each committed change is patched to DynamoDB while the grid shows it, with the old value put back if the server says no. The page also goes full screen on a button, and the form moves from a drawer into a panel of your own.

Cleaning up

As in part 1: delete the function, the table and the role. The inline policy goes with the role.

Read the full source, including lambda/index.mjs and web/index.html, on the public repository, or grab it as a ZIP download and skip the cloning.

Lattice Grid is a JavaScript data grid with charts, dashboards and server-side pushdown, free to develop with on localhost. The row form and the context menu used here are part of the core grid: latticegrid.dev.

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 1: read the data

Tony Goodchild — Tue, 29 Sep 2026 17:13:01 +0000

This is the dev.to edition of a tutorial that lives, with a live copy of the finished grid you can try, at latticegrid.dev/tutorials/crud-dynamodb-part-1.

This is the first of a short series that builds a working application from
nothing: a DynamoDB table, a Node Lambda function in front of it, and a web
page that shows the data in a grid. Part 1 ends with a page that reads
products from your own AWS account. Later parts add creating, editing and
deleting rows.

It is deliberately basic. Everything is done in the AWS Console, there is no
framework, no build step and no infrastructure tooling to install. If you
have used AWS before you will find some steps slow; they are written for
someone who has not.

Source: every file this guide asks you to paste or run is in the
part-1 folder of
toclocoinc/lattice-tutorial-crud-dynamodb
(Code, Download ZIP).

What you need

An AWS account you can sign in to. Everything here fits in the free tier.
Node.js 22 or later on your machine, for the one script that uploads the demo data.
The AWS CLI configured with credentials for that account (aws configure, or aws sso login). Only the upload script uses it.

Pick one region and stay in it for every step. The examples use London,
eu-west-2; any region works.

Step 1: create the table

In the AWS Console, open DynamoDB, then Tables, then Create table.
Table name: Products.
Partition key: sku, type String. Leave the sort key empty.
Table settings: leave Default settings selected. The summary underneath lists what that means; the line that matters is Capacity mode: On-demand, so you pay per request and nothing while idle.
Choose Create table. It is ready in under a minute.

Nothing else about the table needs deciding now. DynamoDB has no schema beyond
the key: every other field on a product is just whatever the item carries.

Step 2: upload the demo data

The download has sixty products in seed/products.json, each with a sku,
name, category, quantity, price and an updated date. The script
beside it writes them to the table in batches of 25, which is the most a single
DynamoDB write call accepts.

cd part-1/seed
npm install
AWS_REGION=eu-west-2 node seed.mjs

You should see three progress lines and then done: 60 products in table "Products". If you named the table something else, set TABLE_NAME too.

Check it in the console: open the table, choose Explore table items, and
the products are there. Notice the order is not the order in the file. DynamoDB
returns items in the order it stores them, which is by a hash of the key. The
grid will sort them for you in a moment.

Step 3: create the Lambda function

Open Lambda, then Create function.
Leave Author from scratch selected. Function name: products-read.
Runtime: leave the default, Node.js 24.x. (Node.js 22.x also works;
both ship the AWS SDK the code imports.)
Open Additional settings at the bottom of the form. Under
Networking, switch on Function URL. A panel opens:
- Auth type: choose NONE.
- Tick Configure cross-origin resource sharing (CORS). The default allows every origin, which is what a page opened from a file needs.
- Choose Save.

Choose Create function. A "Getting started" dialog appears over the new function; choose Dismiss.

The function opens on its Code tab with a small editor. In the explorer on
the left, index.mjs is already selected.

Replace the editor's contents with lambda/index.mjs from the download, then choose Deploy in the panel below the editor. The panel's status changes from "Changes not deployed" to "Current".

The function scans the whole table, one page at a time, and returns the items
as JSON. Sixty products come back in one page; the loop is there so the same
code still works when a table has grown past a page.

Now give it permission to read the table, and tell it the table's name.

Open the Configuration tab, then Permissions in the list on the
left. Under Execution role, click the role name (it looks like
products-read-role- followed by a few letters). That opens the role in
IAM in a new tab. Under Permissions policies, choose Add
permissions, then Attach policies. Search for
AmazonDynamoDBReadOnlyAccess, tick it, and choose Add permissions.
Read-only is enough for part 1; part 2 replaces it with a policy scoped to
this one table. Close the IAM tab.
Back on the function's Configuration tab, choose Environment
variables, then Edit, then Add environment variable. Key
TABLE_NAME, value Products. Save. (Skip this if you kept the default
table name; the code falls back to it.)
Still under Configuration, choose Function URL and copy the URL. It
looks like https://abc123.lambda-url.eu-west-2.on.aws/.

Paste it into a browser tab. You should see JSON beginning {"items":[{.
If you see a permissions error instead, wait a minute; the policy you attached
can take that long to apply.

Two things to be clear about. Auth type NONE means anyone with the URL can read
your products, which is fine for demo data and not fine for anything else;
part 3 puts authentication in front of it. And allowing every origin is a
shortcut for the tutorial; on a real site you would put your own domain there.

Step 4: the web page

Open web/index.html from the download in an editor. Near the top of the
script is one line to change:

const FUNCTION_URL = 'https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lambda-url.eu-west-2.on.aws/';

Replace it with your Function URL, save, and open the file in a browser. You
do not need a web server for this page; a file URL is enough.

The status line at the top reads "60 products from DynamoDB" and the grid
below it shows them. Click Price to sort by price. Click it again to
reverse. Type in the filter row under Category to narrow to one category.
Drag a column header to move it.

That is the whole page. Here is what the thirty lines of script do:

The grid is created first, empty, with six columns and the filter row switched on. Each column names the field it reads from a product. quantity and price are numbers, so they align right and sort numerically. price is formatted as pounds. updated is a date, so it sorts as one rather than as text, and shows as "Jul 7, 2026" rather than the raw 2026-07-07 the table holds.
rowKey: 'sku' tells the grid which field identifies a row. The grid uses it to keep selection and edits attached to the right product when rows move, and part 2 uses it to know which item to update.
fetch calls the Lambda, and grid.rows.load(data.items) puts the products in. That is the only line that touches data.

The grid comes from a CDN, one script and one stylesheet, and shows a small
trial watermark because there is no licence key. Everything works with the
watermark on; a key removes it and does nothing else.

What you have

A DynamoDB table with data in it, a Lambda function that reads it, and a page
that shows it with sorting and filtering done in the browser. Three pieces,
each one you could replace: a different table, a different function, a
different front end.

The one design decision worth noticing is that the Lambda returns everything
and the grid does the rest. With sixty products that is right. With sixty
thousand it is not, and a later part in this series moves sorting, filtering
and paging into the function so the browser only asks for the rows it is
showing.

Part 2: create, edit and delete. Parts 2 and 3 are already published on the site: Part 2 adds the row form and a delete menu, Part 3 adds inline editing with write-back, full screen and the form as a side panel.

Cleaning up

If you are not continuing, delete the Lambda function (Lambda, Functions,
select products-read, Actions, Delete) and the table (DynamoDB, Tables,
select Products, Delete). Deleting the function does not delete the role it
created; find it in IAM under Roles as products-read-role-… and delete that
too. None of it costs anything at this size while idle, but a deleted resource
cannot surprise you later.

Put Splunk Search Results in Your Own App's Data Grid

Tony Goodchild — Mon, 28 Sep 2026 19:53:23 +0000

Products that run on infrastructure have a strong chance of having their events in Splunk. The people who need to see those events are often in your application, not in Splunk, and often without a Splunk seat. The usual answers are an iframe around a Splunk dashboard, or a hand-built table over the REST API that re-implements filtering and paging badly.

Lattice Grid has a Splunk adapter that does the translation for you. This post shows what it does, what it deliberately does not do, and the three ways to handle the credential depending on who the page is for.

The shape of it

Splunk's on-disk index format is closed. There is no file to read and no bucket to open. The supported surface is the search REST API, so that is what the adapter speaks: it dispatches a search job, watches it, reads a window of results, and cancels the job the moment the grid asks for something else.

import { createGrid, createPushdownSource, splunkAdapter } from '@toclocoinc/lattice-grid';
import * as compute from '@toclocoinc/lattice-grid';

const grid = createGrid(el, {
  columns,
  rowKey: 'event_id',
  source: createPushdownSource({
    adapter: splunkAdapter({
      url: 'https://splunk.example.com:8089',   // the management endpoint, not Splunk Web
      search: 'index=security sourcetype=firewall',
      earliest: '-24h',
      headers: { Authorization: 'Bearer ' + token },
    }),
    compute,
    pageSize: 100,
  }),
});

Give it a base search and the grid is live over it. Typing into the filter row, clicking a column header to sort, or scrolling to the next page each becomes a Splunk search job. The browser only ever receives the rows in view.

What a filter turns into

SPL has two ways to say "keep the events where this holds". | where is an eval expression: exact, case-sensitive, applied after the events have been read. The search command's own terms are matched against the index, case-insensitively, with wildcards. The adapter emits the search form, for two reasons. It is the faster one, because Splunk seeks rather than reads and discards. And it is the one whose result matches what the same filter means everywhere else in the grid, whose filter kernel compares strings case-insensitively unless a condition asks otherwise.

That choice has a cost, and the adapter names it rather than hiding it. A condition that asks for caseSensitive cannot be honoured by a case-insensitive matcher, so it is pushed case-insensitively and the grid says so once in the console. Returning quietly wider rows is the failure this adapter exists not to have.

Values never leave their quotes. Strings are wrapped and escaped, including the asterisk, because an unescaped * inside a quoted SPL value is a wildcard. A user who types foo*bar into a filter box gets events containing foo*bar, not everything from foo to bar. The wildcards that contains, startsWith and endsWith need are added outside the escaped text, so the adapter's wildcards are wildcards and the user's are literal. Field names are validated against a pattern and refused by name otherwise, since the identifier is the one part of an SPL expression that cannot be quoted away.

Time filters become the job's window

Splunk's earliest_time is inclusive and latest_time is exclusive. So a >= on the time column maps onto earliest_time exactly and a < maps onto latest_time exactly. The adapter lifts those two out of the filter expression and makes them the job's own window, which is the difference between Splunk seeking to a time range and Splunk reading everything and discarding most of it.

The bounds that do not map exactly, > and <=, and any time condition inside an or, stay in the expression as a numeric comparison on the time field. That is exact, just not as fast. Correct first, fast where correctness allows.

Seeing what was pushed

After each query the source reports what ran in Splunk and what, if anything, stayed in the browser:

grid.on('rows:changed', () => {
  const plan = source.lastPlan();
  console.log(plan.unpushed.length ? 'pushed part' : 'pushed all', plan);
});

For most filter shapes the answer is "pushed all". When it is not, the plan tells you which condition was finished client-side and why, so there is never a silent gap between the filter the user set and the rows they see.

Where the credential lives

The adapter holds no credential of its own. Every request is made with the fetch and headers you supply. It stores nothing, prompts for nothing and refreshes nothing, because an adapter that cached a token would be a place for it to leak from. Three shapes cover the three kinds of page.

Production: a proxy in front of Splunk. Your application authenticates the visitor its own way. A small backend holds the Splunk service token, forwards only the search endpoints, restricts index= to what that visitor may see, rate-limits, and adds the cross-origin headers for your origin. The grid points at the proxy and never sees a token:

const adapter = splunkAdapter({
  url: 'https://app.example.com/splunk',   // your backend, not Splunk
  search: 'index=security sourcetype=firewall',
  earliest: '-24h',
});

The proxy is about forty lines of Node, or a Lambda behind CloudFront. It forwards POST /services/search/v2/jobs, the job's own GET, /results, /export and the DELETE that cancels a job, and refuses everything else. The reference implementation is in the guide linked at the end.

Internal tools: a per-user session key. Behind your own login, each user signs into Splunk with their own account, and the page holds their short-lived session key in memory:

const key = await fetch(url + '/services/auth/login', {
  method: 'POST',
  body: 'username=' + user + '&password=' + pass + '&output_mode=json',
}).then((r) => r.json()).then((j) => j.sessionKey);

const adapter = splunkAdapter({
  url,
  search: 'index=security sourcetype=firewall',
  headers: { Authorization: 'Splunk ' + key },
});

What leaks if the page is compromised is one visitor's own access, and it expires on its own.

Trying it out: your token in the page. Fine for a developer pointed at a development instance, which is what the first example on this page is. Never ship a shared token to visitors. A token grants everything its role can do, across every index it can see, to anyone who reads the page.

A token that expires goes in a fetch wrapper rather than in headers, since the wrapper is the only thing that can mint a fresh value per request.

When you only have an export

Without REST access to the instance, the grid still works from exported results, and exporting is something Splunk does well. From the UI, the CLI, or the REST results endpoint with output_mode=csv or json:

splunk search "search index=security sourcetype=firewall earliest=-24h" \
  -output csv -maxout 0 > firewall-24h.csv

A CSV goes through grid.import, which infers each column's type and previews the mapping before anything lands. A JSON or NDJSON export goes through createUrlSource, which streams NDJSON line by line and renders the first rows before the rest has arrived. The REST route is the one worth automating: a scheduled job that lands a fresh export, with nobody exporting anything by hand.

There is a third route for teams already using Splunk's Ingest Actions to land events in S3 as NDJSON or JSON. What arrives there is ordinary files in a bucket you own, and the grid's DuckDB adapter reads them directly, with filters pushed into DuckDB the same way they are pushed into Splunk here. That works because Ingest Actions writes an open format to a destination you control. Pointing the grid at Splunk's own storage is not something it does.

Try it

There is no public Splunk instance or credential a website can publish, so the live demo runs the adapter against a mock of the search REST API. Everything above the mock is the real code path: https://www.latticegrid.dev/demos/pushdown-splunk/

The full guide, including the reference proxy: https://www.latticegrid.dev/docs/sources/splunk/

Building a live network operations wall in one HTML file

Tony Goodchild — Fri, 25 Sep 2026 14:57:19 +0000

A NOC wall is the hardest kind of dashboard to build well. Nineteen panels, one stream of events, every panel wanting a different cut of the same data, and all of it updating every second without a repaint storm. Most teams end up with a data layer per panel, a timer per chart and a pile of glue code nobody wants to touch.

This demo does it with one page, one data feed and no glue. It is live at https://toclocoinc.github.io/lattice-grid-demo-noc-umd/ and the source is public at https://github.com/toclocoinc/lattice-grid-demo-noc-umd. Everything below is in that repository.

The wall

The page is a 20 by 20 layout of movable, resizable windows. A branding tile and six KPI tiles run along the top, with two clocks for London and New York. Underneath sit a world map of sites, a core network topology, the active alarms grid, service health, network traffic, link utilisation, incident trend, a site status donut, the top affected sites and a scrolling alarm ticker.

Every one of those windows is fed by the same stream. That is the point of the demo.

The layout component

The layout module gives you a grid of windows and nothing else to think about. Each window is declared with an id, a title, a position and a size:

{ id: 'map', title: 'Global network overview', xPos: 1, yPos: 3, xSize: 8, ySize: 9 }

The module renders the chrome, handles drag, resize, maximise and close, and hands you a body element per window (<id>-body). You mount whatever you like into it: a grid, a chart, a KPI tile, a plain div. Windows that should not move, such as the branding tile, are simply declared movable: false.

There is no framework in the page. It is plain HTML, a handful of script tags from the CDN, and one script block.

The data router

The data router is where the wall stops being nineteen problems and becomes one. Every event in the feed carries a kind: site, alarm, service, sample, element, chip or metric. The router is created once, keyed on that field:

createDataRouter({ key: 'kind', rowKey: 'id', overlap, batch, coalesce })

Then each viewer attaches to the route it wants, before the stream starts:

data.attach(alarmGrid, 'alarm')
data.attach(siteGrid, 'site')
data.attach(serviceGrid, 'service')
data.attach(trafficGrid, 'sample')

That is all the wiring. A row with an existing id is an upsert. Bursts are coalesced. A grid attached to the alarm route gets only alarms, the site grid gets only sites, and neither knows the other exists. When a BGP session flaps for the fourth time the alarm row escalates in place, the KPI counting active incidents ticks up, the ticker prints the update and the incident trend adds a bar. Nobody wrote code to keep those in step.

The best part is derived sources. A chart that wants "the five busiest links" does not need a second feed. It sits on a derived grid:

source: { mode: 'derived', from: linkGrid, sort: [['load', 'desc']], limit: 5 }

The site status donut is a derived grid grouped by status with a count. The top affected sites panel is a derived grid over the alarm grid, grouped by site. Each is a viewer of a viewer, and they stay live for free.

The charts

Six chart types share the wall, and each one is a viewer of a grid, so the charts never hold data of their own.

World map of every site, drawn with the world geometry pack, marker colour by availability, label by city.
Network topology with pinned nodes for the internet edge, two cloud regions, four core routers and four regions. Nodes are glyphs from the icon registry, links are coloured by utilisation rules.
Link utilisation as horizontal bars, coloured by the same rules and labelled with the value.
Network traffic as a line chart of the sample route, one series per direction.
Incident trend as a stacked bar per minute, one series per raised severity, on a rolling time axis.
Site status donut with a named colour scheme, a legend with counts and the total in the centre.

The service health grid uses the grid itself as a chart surface: an icon per service, availability coloured as text by SLA rule, and a sparkline cell rendered from the last few readings. An alarms module sits on that grid and raises its own alarm when availability drops below the SLA thresholds, which feeds the same ticker as the network alarms.

Colour rules are declared once as formatting rules and shared. When a link goes amber in the topology it goes amber in the bar chart, because it is the same rule.

The data source

The feed is real. The backbone is a real carrier (AS3257), its sites are the carrier's PeeringDB facilities, so the world map shows real cities with real coordinates. Route updates come from RIPE RIS Live, the public BGP stream from RIPE's collectors. Internet outage detections come from IODA at Georgia Tech.

Live BGP does not make for a reliable public demo, so the page ships with a ten minute recording of the RIS stream and replays it in a loop. The replay is stamped with the wall clock as it plays, so the per-minute incident trend and the alarm ages behave as though the events were arriving now. The page also supports a live mode that opens the RIS websocket and reads PeeringDB directly, and a simulated mode for offline use.

All of that is in a single data file that produces the events. The router does not care which mode is running.

What the demo drove

Building the wall in public found gaps worth closing, and they shipped in the same week. The geometry packs and every chart gained UMD and CommonJS builds so the map works from a script tag (1.71.1). Bars can be coloured by rule and labelled (1.71.1). Chart series can be coloured by name, legends can show counts and a donut can carry a centre value (1.71.3). Each of those is in the demo today.

Try it

Open the live page, drag the windows around, and watch the alarms grid and the ticker for a minute. Then read the page source. It is one file, and the wiring is shorter than this post.

Live demo: https://toclocoinc.github.io/lattice-grid-demo-noc-umd/
Source: https://github.com/toclocoinc/lattice-grid-demo-noc-umd
Lattice Grid: https://www.latticegrid.dev

We built a data grid for technical data. Here is what a column type has to know.

Tony Goodchild — Thu, 24 Sep 2026 12:27:32 +0000

Most data grids know at least four kinds of value: text, number, date, boolean. That is fine for an order list. It falls apart the moment the data is a link budget, a pressure log, a register dump or a fleet of IP addresses, because every one of those has rules that a plain number does not know.

A gigabyte column that shows 0.5 is wrong. A temperature column with a footer total is wrong. An average bearing of 359° and 1° that reads 180° is wrong in a way that looks right. You can format the output easily, but then you have to start building custom comparators for sorting, and have to enforce how data is entered.

I built Lattice Grid for applications (like our others) that show real amounts of technical data, so the type system had to carry that knowledge instead of leaving it to every screen.

A type is a bundle of behaviour, not a label

In Lattice Grid, setting type on a column configures everything at once: how a value is formatted, how typed text is parsed back into a value, how two values compare when sorting, how the column is stored in the columnar backing, what lands in Excel, and what goes on the clipboard.

columns: [
  { field: 'span',      type: 'metres' },       // 1500     → "1.5 km"
  { field: 'inlet',     type: 'pressure' },     // 200000   → "200 kPa"
  { field: 'cap',       type: 'capacitance' },  // 4.7e-11  → "47 pF"
  { field: 'bearing',   type: 'degrees' },
  { field: 'inletTemp', type: 'celsius' },
  { field: 'gateway',   type: 'ipv4' },
  { field: 'flags',     type: 'hex32' },
]

We have 7 core types (text, number, boolean, date, dateString, object, lookup) and 88 technical ones ship, grouped by domain:

Temporal: datetime, timestamp, time, duration
Network: ipv4, ipv6, cidr, mac
Numeric bases: hex, hex8, hex16, hex32, binary, binary8, octal
Computing units: bytes, megabytes, gigabytes, bitrate, gigabits
Physical and engineering units: length, mass, duration, speed, acceleration, area, volume, energy, power, force, pressure, torque, density, flow and angle
Electrical and scientific: voltage, current, resistance, capacitance, inductance, charge, conductance, flux density, illuminance, absorbed and equivalent dose, radioactivity, molarity, viscosity, thermal conductivity, frequency and more
Temperature: celsius, fahrenheit, kelvin
Currency: currency, usd, eur, gbp, jpy
Structured: json, colour, rating, percent
Units: store one number, make only the display unit-aware

Units: store one number, make only the display unit-aware

The design rule for every unit type is the same. The column stores a plain number in a named base unit, and only display and input know about units. A gigabyte column holding 0.5 shows 512 MB, accepts 512M typed over it, and stores 0.5 throughout. Because the backing is still a typed array, sorting, filtering, grouping and totals are ordinary arithmetic and never touch rendered text.

display: 'auto' walks the coherent SI ladder and picks the largest unit that fits. significantFigures rounds to a fixed precision rather than a fixed number of decimals, and rounding happens before the unit is chosen, so 999,999 bytes to three figures is 1.00 MB, not 1,000 kB. compound: ['ft', 'in'] renders one stored number as 5 ft 11 in and parses it back the same way.

Seventeen unit systems ship, and you can add your own:

import { registerUnitSystem, defineUnit, createUnitType } from '@toclocoinc/lattice-grid';

// factor is how many BASE units one of these is. Exactly one must be 1.
registerUnitSystem('yarn', [
  defineUnit('tex',  1,     ['tx']),
  defineUnit('ktex', 1e3,   [], { prefix: 'k' }),
  defineUnit('den',  1 / 9, ['denier']),
]);

createGrid(el, {
  dataTypes: { linearDensity: createUnitType({ system: 'yarn', unit: 'tex', display: 'auto' }) },
  columns: [{ field: 'count', type: 'linearDensity' }],
});

The rules that protect the data

Three decisions in the unit layer are there because the alternative is silent corruption.

Ambiguous units are refused, not guessed. A US gallon and an imperial gallon differ by about a fifth, and "ton" means three different masses. Each has its own symbol (gal (US), ton (UK)), and the bare word is rejected on input rather than resolved to a default. The same rule catches case: mV and MV are a billion apart, so both exact spellings work and mv is refused.

Customary units are accepted but never chosen. With the calorie, the BTU and the kilojoule all on one ladder, auto would render 4,000 J as 3.79 BTU because the BTU happens to be the larger unit. So auto walks SI only; ask for a BTU by name and you get one.

Some quantities are not units at all. Temperature carries an offset, so no factor converts it: celsius, fahrenheit and kelvin convert on input (type 72 F into a Celsius column and it stores 22.2) and refuse to be summed, because twenty degrees plus twenty degrees is not forty. Angles wrap, so a degrees column averages by direction and reports nothing when the angles cancel, while the sum stays arithmetic because 720° of total rotation is a real figure. Currency is an amount and a code, never a fixed factor; you pass a rate source to createCurrencyType, and a rate that is needed but absent renders as a loud missingRate marker, never as zero.

Time: a wall clock and an instant are different types

A date column stores '2024-03-11' as a string, not a Date. new Date('2024-03-11') is midnight UTC, which renders as the 10th in New York, so a delivery date set in London would show a day early in Mumbai. Storing the wall-clock string means the date a user typed is the date everyone sees. It is also faster: ISO 8601 sorts lexicographically in chronological order, and repeated dates dictionary-encode well.

When you mean a genuine moment, an audit time or a cross-region log line, use timestamp. It ingests epoch-millis, a Date or a zone-bearing ISO string, stores epoch-millis UTC, and sorts, filters and compares on the instant, so rows from different origin zones order by true chronology and changing the display zone never reorders them. The display zone resolves from the column, then the grid, then the viewer, and is nameable in the cell (Europe/London (BST)), with showOrigin: true when the origin differs. Grouping buckets by civil day in the display zone, so a 23- or 25-hour daylight-saving day still collapses to one bucket. Excel export writes the display-zone wall clock and names the zone, never a silent shift to UTC.

Types the grid reads from your data

A column that declares no type takes one from the rows. The first hundred non-empty values are sampled, and a type is adopted only if every one matches; anything mixed stays text and says so once on the console.

columns: [
  { field: 'sku' },        // text
  { field: 'quantity' },   // number: aligned right, numeric filter
  { field: 'shipped' },    // date
  { field: 'expedited' },  // boolean: checkbox editor
]

Only the core names are ever inferred, so a column of IP addresses or durations is text until you name the type. Inference never overrules a decision you made, and type: false turns sampling off. Sorting is not what you gain by declaring: the default comparator is already value-aware, so an undeclared IPv4 column already orders correctly across 128.0.0.1. What a declared type settles is everything around the sort: the editor, the parser, the formatter, the filter kind, the storage, and the export.

Building a type to order

Two factories cover most custom cases. createUnitType you have seen. createRadixType builds a register view:

dataTypes: {
  reg32: LatticeGrid.createRadixType({
    radix: 2, bitWidth: 32, pad: true, signed: false, group: 8,
  }),
},
columns: [{ field: 'flags', type: 'reg32' }],
// 170 → 0b00000000 00000000 00000000 10101010

Base 10 is deliberately not among the radices: a decimal number is what number is for, with grouping, decimals and currency that a radix formatter has no concept of. Pass radix: 10 and the console names the supported set and falls back to hex, rather than producing something that looks like a number column and is not one.

When a factory is not enough, a type is a plain object with a small set of properties for you to set:

Member	What it decides
`base`	The storage family: text, number, boolean, date, dateString or object
`extends`	The type to inherit from; `defaults` merge rather than replace, so a derived type overrides one default and keeps the rest
`matches`	Whether a sampled value belongs to this type, for inference
`format` / `parse`	Display text out, typed or pasted text back in
`compare`	Sort order
`defaults`	The filter kind, editor, footer total, alignment and cell renderer a column gets for free
`storage`	`float64`, `int32`, `bitset`, `dictionary` or `object`
`totals`	Which aggregates mean something for this type, and the type's own reduction for each

That last member is the one we are really finding useful. A type can declare which aggregates are meaningful.

Formats, when you need them
On top of a type sits an optional format, with a shorthand for the common cases and a full spec when the shorthand runs out:

A key in format that the resolved type does not read, a typo or a key from a different shape, is never silently dropped. It warns once, by column and key name.

Why this matters

I spent a lot of time talking to the people who were using our SAAS for 8 hours a day, looking at grids on the screen. It was their frustrations and comments that led to Lattice Grid. Making their lives easier so they don't have to type in 10GB when something they are pasting into a cell says 10000MB. Making sure they don't enter 10,000GB by mistake.

The grid carries the rules, so your users do not have to carry them in their heads, and a wrong number fails loudly at construction instead of quietly in a report later.

The built-in types: JavaScript Data Grid Demo | Lattice Grid

text, number, dateString, boolean, lookup, object, json, secret and image, one column each. A live JavaScript data grid demo you can drive in the browser.

latticegrid.dev

DEV Community: Tony Goodchild

Every data grid claims to handle live data.

Chart a derived grid: source and derived data in one live chart

Chart a derived grid: source and derived data in one live chart

What a derived grid is

Why that works

A chart that follows a filter

Source and derived data in one chart

When not to reach for one

We Migrated 166 Grids off AG Grid. Here's What Broke.

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 3: edit in place

Step 1: the function learns PATCH

Step 2: allow PATCH through the URL

Step 3: the page

Step 4: check the table

What you have

Where to go next

Cleaning up

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 2: add and delete

Step 1: teach the function two more verbs

Step 2: allow the new verbs through the URL

Step 3: give the function the permission it needs, and no more

Step 4: the page

Step 5: check the table

What you have

Next

Cleaning up

Build a CRUD app with a JavaScript grid, Node and DynamoDB. Part 1: read the data

What you need

Step 1: create the table

Step 2: upload the demo data

Step 3: create the Lambda function

Step 4: the web page

What you have

Next

Cleaning up

Put Splunk Search Results in Your Own App's Data Grid

The shape of it

What a filter turns into

Time filters become the job's window

Seeing what was pushed

Where the credential lives

When you only have an export

Try it

Building a live network operations wall in one HTML file

The wall

The layout component

The data router

The charts

The data source

What the demo drove

Try it

We built a data grid for technical data. Here is what a column type has to know.

The built-in types: JavaScript Data Grid Demo | Lattice Grid