Live Updates

One call, and the row changes where it stands

A grid that has already rendered does not need refetching to show new data. Hand it a transaction — up to three lists in one object — and it applies them in place:

grid.applyTransaction({
  update: [{ id: 7, price: 184.32, change: 1.24 }],   // matched by trackBy
  add:    [newRow],
  remove: [oldRow.id],                                 // rows OR bare ids
  addIndex: 0,                                         // where adds land; default is the end
});

The call returns a TransactionResult describing what actually changed, and (liveUpdate) fires with the same object.

trackBy is mandatory

update and remove match rows by stable id, so config.trackBy has to name the id field. Without it, rows are matched by object reference, which fails the moment a payload arrives as a fresh object — which is always. The grid warns once if you call a transaction without it.

You own the subscription

The grid does not connect to your WebSocket, poll your API, or hold a socket open. Your component does, and calls applyTransaction() with what arrives. That keeps reconnection, back-off, authentication and teardown where your app can see them — and it means any source works: a socket, server-sent events, a poll, a signal effect, a router event.

Cell flash — what moved, and which way

With live.flashCells: true a changed cell animates for live.flashDuration ms (default 700): green with a ▲ when a numeric value rose, red with a ▼ when it fell, neutral otherwise. live.flashColumns narrows it to the columns worth watching, so a row whose every field changed does not light up end to end. Flash respects prefers-reduced-motion and is a decoration only — the data lands either way.

Keeping a feed bounded

A feed left open all day grows until the tab does. live.maxRows makes the grid a ring buffer: once an add pushes the loaded count past the cap, the oldest rows are dropped. Set it to whatever a reader can actually scroll back through.

Transactions and an active filter

With filterApplyMode: 'client' the grid filters loaded rows itself, so an update that pushes a row out of the active search or column filter makes it disappear on its own, and one that brings a row in makes it appear — no refetch. Under the default 'server' mode your data source owns filtering, so live edits are not re-filtered until the next fetch (the grid warns once, so it is never a silent disagreement).

Bursts

Each call applies immediately, which is what makes the change visible in the same frame — and means a burst of 500 calls is 500 renders. Batch them yourself: collect messages for a frame and send one transaction with 500 rows in its update list, which is one render — the same work the grid would have done, decided by the code that knows how fast the messages arrive.