JavaScript Data Grid

A JavaScript data grid is a component that renders tabular data and keeps it usable at a size where a plain HTML table stops working. It virtualizes rows, so only the ones on screen exist in the DOM, and it ships the interactions you would otherwise write yourself: sorting, filtering, in-cell editing, column pinning and keyboard navigation.

ApexGrid is the one in this family. It is a standards-based custom element, so it works in plain HTML and inside React, Vue or Angular without a wrapper:

$npm install apex-grid

<apex-grid id="grid"></apex-grid>

<script type="module">
  import 'apex-grid/define'

  const grid = document.getElementById('grid')
  grid.columns = [
    { key: 'account', headerText: 'Account' },
    { key: 'revenue', headerText: 'Revenue', type: 'currency' },
    { key: 'health', headerText: 'Health', type: 'status' },
  ]
  grid.data = [
    { account: 'Northwind', revenue: 491611, health: 'healthy' },
    { account: 'Contoso', revenue: 485513, health: 'at risk' },
  ]
</script>

Do you actually need a data grid?

A grid is a real dependency. It is worth taking on when the table has work to do, and not before.

What you need	Reach for
A few hundred read-only rows, no interaction	A plain <table>. It costs nothing and is fully accessible by default.
Sorting and a search box over a few hundred rows	A plain table plus your own sort and filter. Roughly 40 lines.
Thousands of rows, or any scroll performance concern	A data grid. Virtualization is the thing you should not write yourself.
Editing values in place, with validation	A data grid. In-cell editing plus keyboard commit and cancel is far more work than it looks.
Grouping, subtotals or pivoting	A data grid with an analytics tier.
Comparing magnitudes rather than reading values	A chart, not a table. If nobody needs the exact number, a table is the wrong shape.

The last row is the one worth pausing on. A grid of 5,000 numbers that people only scan for outliers is a chart nobody drew yet.

What ApexGrid ships in each tier

Community is the grid. Enterprise is the analytics layer on top of it, as a drop-in <apex-grid-enterprise> element that inherits every Community feature.

	Community	Enterprise
Virtualized rows and columns	Yes	Yes
All 13 column types	Yes	Yes
Sorting, filtering, quick filter	Yes	Yes
Inline editing and cell validation	Yes	Yes
Column pinning, reordering, groups	Yes	Yes
Row selection, expansion, pinning, reordering	Yes	Yes
Tree data, pagination, state persistence	Yes	Yes
CSV export	Yes	Yes
Row grouping and aggregations	No	Yes
Pivoting	No	Yes
Range selection	No	Yes
Integrated charts	No	Yes
Formula engine	No	Yes
AI toolkit	No	Yes
Excel export	No	Yes

Community is included on every plan and is free for organizations under $2M in annual revenue. Enterprise requires the Premium or OEM plan. Nothing here is open source: source being published on GitHub is not the same thing as an open licence. The full matrix is on the ApexGrid page and the pricing page.

The 13 column types

A column's type decides how it renders, how it sorts, and which editor it uses in inline-edit mode. As of apex-grid 3.4.0 there are thirteen:

Type	Renders as
string	Plain text. The default.
number	The value as-is, in tabular figures. No thousands separators
boolean	A checkbox, editable in place when the column is editable
select	A dropdown of options, accepting bare values or { value, label } pairs
date	A formatted date. YYYY-MM-DD is read as a floating date, so it shows the same calendar day in every timezone
rating	A star rating
image	An image from the cell value
avatar	A circular avatar
currency	A formatted money value
badge	A pill
status	A coloured dot plus label, with the variant inferred from the value or set by statusVariant
progress	A progress bar
sparkline	An inline mini chart

For anything else, a column's cellTemplate takes over rendering entirely. It receives the cell value and returns a Lit template:

{
  key: 'revenue',
  headerText: 'Revenue',
  type: 'number',                                  // numeric filter operands
  cellTemplate: ({ value }) => `$${(value / 1000).toFixed(0)}k`,
}

Keeping type: 'number' alongside the template matters, but not for the reason you might expect. Sorting compares the stored values, so it is numeric either way. What the type decides is the filter operands: only number and boolean get their own sets, so number is what gives the column "greater than" instead of "contains". A type: 'currency' column formats money automatically but can only be filtered as text, which is the tradeoff the column-types reference lays out in full.

Where a different grid is the better choice

Being honest about this is more useful than pretending otherwise.

• Your component library already has one. If you are already shipping a design system with a table component that virtualizes, using it costs you nothing extra and keeps one set of theming tokens.
• You need a spreadsheet, not a grid. Multi-sheet workbooks, cell references across sheets and a full formula surface are a different product category. ApexGrid Enterprise has a formula engine, but it is a grid with formulas rather than a spreadsheet application.
• Server-side everything at very large scale. ApexGrid Enterprise has an infinite row model for paging data in from a server. If your requirement is that grouping, sorting and aggregation all execute in the database over hundreds of millions of rows, evaluate that path specifically rather than assuming any client grid covers it.

Using a grid with charts

The common case is a grid and a chart on the same screen, filtered together. Clicking a chart bar to filter the table is its own recipe, including the part that usually breaks:

Drill down from a chart into a grid