Skip to content

View Refresh

ZenGrid renders only the cells in view and reuses their DOM as you scroll. When the data behind a cell changes, the grid doesn’t watch your objects — you tell it what to repaint. Which method you call depends on how much changed, from a single cell up to the whole viewport.

Every method below lives on the grid instance.

Method Repaints Use when
updateCells(cells) Just the listed cells A few known cells changed.
refresh() All visible cells Many values changed; you don’t want to track which.
clearCache() Drops cached render output, then repaints A renderer’s output logic changed, not just the value.
render() Full (re)paint First mount, or after a structural change. Idempotent.
updateOptions(opts) Applies option changes, then refreshes You changed grid options at runtime.
interface CellRef { row: number; col: number }
grid.updateCells([{ row: 0, col: 3 }, { row: 2, col: 3 }]); // two cells
grid.refresh(); // every visible cell
grid.clearCache(); // forget cached output, then repaint

updateCells is the cheapest — it repaints only the cells you name, so live tickers and inline edits stay smooth even over huge datasets. Reach for refresh() only when you genuinely don’t know which cells moved.

// A value changed at row 4, column 3 — repaint just that cell.
rows[4][3] = 91_500;
grid.updateCells([{ row: 4, col: 3 }]);

Replacing the whole dataset is a different call: setData swaps the rows and auto-renders (unless you set autoRender: false), so you don’t call refresh after it.

grid.setData(nextRows); // repaints on its own

Header cells repaint separately from body cells:

grid.updateHeader(2); // one column's header
grid.updateAllHeaders(); // every header cell
grid.refreshHeaders(); // re-run header renderers

This grid mutates the revenue of the top rows every 700ms and repaints just those cells with updateCells — the rest of the grid is never touched. Open Code or Split and try it: widen the loop to more rows, swap updateCells for a blanket grid.refresh(), or change the interval.