Our DataGrid answers that with one option, editing.mode, and since the 16 October release all five modes are in the free packages: @kanunilabs/datagrid-react 1.8.1 and @kanunilabs/datagrid 1.9.1 for plain JavaScript. No licence key, no watermark. This post goes through the five on the same 240 real order lines and shows exactly what each one hands to your code.

The demo loads only the free package. The order lines are the last 240 product lines sold to customers in France in December 2011, from the Online Retail II dataset. The screenshots use the Emerald colour scheme with the Elevated layout; you can switch both in the demo, or make your own scheme in the Theme Builder.

The one option

import { DataGrid } from '@kanunilabs/datagrid-react';
import '@kanunilabs/datagrid-react/styles.css';

<DataGrid
  gridId="orders"
  dataSource={rows}
  rowKey="id"
  columns={columns}
  editing={{
    mode: 'batch', // 'cell' | 'batch' | 'row' | 'form' | 'popup'
    onSave: async (changes) => {
      await api.save(changes);
      setRows((current) =>
        current.map((row) => {
          const change = changes.find((c) => c.rowKey === row.id);
          return change ? { ...row, ...change.values } : row;
        }),
      );
    },
  }}
/>

Every change that reaches onSave carries the row key, values with the changed columns only, and oldValues with what they were before. Columns with editable: false stay closed. In the demo that is Invoice, Date, Stock code and Customer; only Product, Qty and Unit price can be changed.

Cell: every value is saved on its own

cell is the free grid's default. Double-click a cell, press F2 or just start typing; Enter commits and moves down, Tab moves to the next editable cell, Esc cancels. The grid writes the new value into the row and calls onSave with that one change.

Two edits in the screenshot, two calls: {"quantity":24} for row 1, then {"price":2.1} for row 3. This suits a table where each value stands on its own, such as a stock count or a list of settings, and where an auto-save is what users expect. It does not suit a change that only makes sense together with another one: the first half is saved before the second is typed.

Batch: change many cells, save them together

In batch mode nothing is saved while the user types. Changed cells get a small marker in their corner, and a Save / Cancel strip appears above the grid with the number of rows waiting.

Save sends everything in one call: both rows, each with only the column that changed.

Cancel puts every cell back. This is the mode for a screen where someone reviews a set of numbers before committing them: a price list, a budget, an order that is checked line by line. It also gives your server one request to accept or refuse as a whole.

Row: open one record in place

row opens every editable cell of one row at once, by double-click or by Edit row… in the row's right-click menu. The strip above the grid says which row is open, with Save row and Cancel.

Only that row is saved. If the user has half-finished something elsewhere, it stays where it was. Use it when a record is one line of a few short fields and people edit one at a time.

Form: the same record under the row

form lays the same row out as a labelled form, opened under the row in the table's flow. Ctrl+Enter saves and Esc cancels, and the buttons are on the form itself.

A form is easier to read than a row of narrow cells when a record has more fields than fit on the screen, or long values such as an address. Because it opens in place, the rows above and below stay visible for comparison.

Popup: the same form in a dialog

popup puts that form in a dialog over the grid.

The table does not move, so this suits a long table where opening a form in the middle would push the rows the user was looking at off the screen. Row, form and popup share one editing session underneath, so Save and Cancel behave the same way in all three. They differ only in where the fields are drawn.

What this costs

In cell mode the grid writes the new value into your row object. In the other four it writes nothing into your rows: the change waits until Save, goes to onSave, and is then cleared from the grid. If your handler does not write it into your data, as the setRows call above does, the cells show the old values again after Save. That is the line every mode but cell needs, and the one most easily forgotten.

Throw from onSave and the changes stay pending, so a refused save loses nothing the user typed.

Two things we noticed while taking these screenshots, both on our to-do list: in the form and the dialog, the fields of editable: false columns are locked but look the same as the open ones; and in row mode the number editors align their values to the left while the cells align them to the right.

Free and paid

The five modes, the Save / Cancel strip, the edit form and the dialog, valueParser and valueSetter, and the same modes in plain JavaScript through createGrid are free. Validation rules, adding and deleting rows, per-row permissions, lookup and custom editors, undo and redo, and range selection with fill and paste are in the Enterprise edition. The order editing demo shows validation and undo on the same rows, and the pricing page has the rest.

Try it

Open the demo, switch the mode, change a few quantities and prices and watch what onSave receives. The editing docs cover each mode and its keys, and an earlier post goes deeper into what a batch save should send to a server and what happens when the server says no.

Disclosure: this article was drafted with AI assistance. Every screenshot was taken from the live demo, and every payload shown was logged by it, in October 2026.

So we built two apps the way a customer would: a customer manager on the DataGrid and a sales report on the PivotGrid, both in React. They run in the browser on made-up data, with no sign-up, and nothing you type leaves the page. There is a one-minute video of both:

https://youtu.be/uOVkTqPYh60

The rest of this post goes through each app screen by screen, then through the nine bugs in our own product that building them turned up.

Customer Management

Customer Management is the customer module of a CRM: 2,500 accounts, each with a status, a segment, a region, an account owner, orders and revenue. The screenshots use the Lagoon colour scheme with the Framed layout, picked from the bar at the top of the app. Both come from the Theme Builder, where you can also make your own scheme.

The five figures at the top are computed from the rows in view, so they follow every filter, search and saved edit. Under them are the saved views (All customers, At-risk accounts, Enterprise by revenue, By owner) and the quick filters. A status chip writes the same condition as the Status column's own header filter, and the sentence under the grid reads it back, so there is one filter, not three that can disagree.

Tick a few customers and a bar appears to reassign them to another owner, change their status or export only those rows. Cells are edited in place and wait in the grid until you press Save. Type a broken email address into a customer's row and the grid refuses it before it reaches the app's data.

The arrow at the start of a row opens its detail panel: contact details, the five most recent orders and the account notes. The orders come from the same seeded history as the row's Orders and Revenue columns, so they add up to the cent.

The Chart button in the grid's toolbar opens the grid's own chart panel above the table: revenue by segment, over the rows in view. A click on the Mid-market bar filtered the table to Mid-market, as above; a second click clears it. The panel's toolbar changes the chart type and the column, downloads PNG or SVG and goes full screen.

Sales Analytics

Sales Analytics is the report a sales team opens on Monday: 20,000 orders and 43,472 order lines of a made-up hardware and software supplier, in four regions, from January 2024 to September 2026. These screenshots use the Indigo scheme.

The filters at the top (period, region, category, channel) feed both the six figures and the pivot. The figures and the pivot read the same rows, and the app checks it: the line under the figures says total revenue equals the pivot's grand total, and gives the number. Five tabs load ready-made analyses (regional overview, category by month, year over year, rep performance, channel mix). Any of them can be rearranged by dragging fields between the filter, row, column and value areas.

Click any number to see the order lines behind it. Above, the cell for Australia in 2026 opened a window with its 795 order lines, which can be searched and exported on their own.

The chart under the pivot is drawn from the pivot's result, so it changes when the pivot does. A click on a bar or a slice filters the pivot to that country.

Free and paid

Most of what you see is in the free packages. In Customer Management: sorting by several columns, filtering, search, the column chooser, pinning, row selection, one level of grouping, footer totals, CSV export and colour schemes. Editing in place and saving in a batch is also free since the 16 October release. In Sales Analytics: the pivot itself, dragging fields, the filters, the display modes and CSV export.

The validation rule that refuses the broken email, the detail panel, the charts, the drill-down window, group subtotals, Excel export and the status bar are in the Enterprise edition. Both apps put an Enterprise tag next to each of those, so you never have to guess. Prices are on the pricing page.

The nine bugs

We expected the apps to show the product. We did not expect them to test it. Building them turned up nine bugs in our own packages, each of which had passed every existing test:

1. A "count distinct" on a text field showed 1 in every cell of the pivot.

2. Exporting the pivot's rows to CSV or Excel XML stopped with an error when a field had a formatting function.

3. The field settings dialog had no "count distinct" option for text at all.

4. The pivot's chart ignored the "% of total" and running-total display modes and drew the raw sums.

5. The React pivot chart cut long category labels at a fixed 60 px.

6. The same chart wrote "14000k" on its value axis.

7. In the React DataGrid, clicking the arrow that opens a row's detail panel also selected the row.

8. The detail panel was as wide as all the columns together, so on a narrow screen it ran off the side.

9. Batch editing showed an empty toolbar strip when there was nothing to save.

All nine are fixed and on npm since the 15 October release, and each fix came with a test that fails on the old code.

What we take from it: a one-feature demo tests a feature, and a real screen tests the places where features meet. Almost every bug above sat between two of them: a chart and a display mode, row selection and the detail panel, an export and a formatting function. Each piece had its own tests. Nothing tested them together until a screen needed both.

Try it

The two apps are at /demos/customer-management and /demos/sales-analytics. Change the colour scheme, tick a few customers, drag a field into the columns, click a number. If anything feels slow or wrong on your machine, we would like to hear about it on the contact page.

For the parts underneath: the DataGrid docs cover filtering, saved views, editing and grouping, the PivotGrid docs cover fields, display modes and drill-down, and an earlier post builds a sales report step by step.

Disclosure: this article was drafted with AI assistance. Every number in it was read from the live apps and from our engineering log in October 2026. The customers, orders and figures in the apps are made up.

The endpoint behind it is usually written in an afternoon: turn the request into WHERE, ORDER BY, LIMIT and OFFSET, run it, return the rows and a count. This post runs that version against a real table and compares it with what the grid would have shown with the data in the browser. The data is the 1,067,371 invoice lines of Online Retail II, a UK online gift shop's sales from December 2009 to December 2011, loaded into PostgreSQL 16 on a laptop. 243,007 of those lines have no customer number, and that turns out to matter.

The grid is our free DataGrid for React with its REST data source. The screenshots use the Teal colour scheme with the Ledger structure, both from the Theme Builder. The server half is @kanunilabs/datagrid-server, which is also free. The sections below go through five ways the usual endpoint goes wrong, then what the correct version costs and the indexes that pay it back. An earlier post covers the browser half: what the grid sends and why.

The page and the usual endpoint

On the page, the grid gets a URL instead of an array:

import { DataGrid, createRestDataSource } from '@kanunilabs/datagrid-react';

const source = createRestDataSource({ url: '/api/invoices', distinctValues: true });

<DataGrid dataSource={source} rowKey="id" columns={columns} toolbar filterRow headerFilter style={{ height: 640 }} />;

Each request carries skip, take, and the sort and filter as JSON. This is the endpoint most of us would write first. Every value is a bound parameter, so it looks safe:

const where = [], params = [];
const p = (v) => (params.push(v), `$${params.length}`);
for (const f of filters) {
  if (f.operator === 'contains') where.push(`${COL[f.columnId]} LIKE '%' || ${p(f.value)} || '%'`);
  if (f.operator === '<>') where.push(`${COL[f.columnId]} <> ${p(f.value)}`);
  if (f.operator === '=') where.push(`${COL[f.columnId]} = ${p(f.value)}`);
}
const order = sort.map((s) => `${COL[s.columnId]} ${s.direction}`).join(', ');
const sql = `SELECT … FROM invoices ${where.length ? 'WHERE ' + where.join(' AND ') : ''}
             ${order ? 'ORDER BY ' + order : ''} LIMIT ${p(take)} OFFSET ${p(skip)}`;

1. Rows that appear twice while scrolling

Sort the grid by stock code and scroll. The same invoice line shows up again a few rows further down, and another line never shows up at all:

Thousands of lines share each stock code, and SQL does not promise any order among equal values. Every block of 100 is a separate query, and PostgreSQL is free to break the ties differently each time. We scrolled through the first 10,000 rows, which is 100 blocks. Sorted by stock code, about 2,250 lines appeared more than once, so at least 2,700 of the lines that belong there never appeared. Sorted by quantity it was about 2,100 and 2,650. The exact counts change from run to run, which is the problem. Sorted by country or by date there were none, because those columns had an index, and reading an index happens to return ties in the same order every time. That is why this passes testing on one column and fails on the next. With no sort at all, the endpoint has no ORDER BY, and the first page of the not-equal screenshot below begins at line 267,617.

The fix is one more sort term: end every ORDER BY with the row's unique key, here id. The package adds it to every query once you give it the key.

2. "Not equal" drops the empty cells

Filter the Customer column to <>17841. The grid should hide that one customer's lines. The hand-written endpoint hides 243,007 more:

In SQL, NULL <> 17841 is neither true nor false, so WHERE drops every line without a customer number. To the person using the grid, an empty cell is not equal to 17841, and that line should stay. The package writes (customer_id IS NULL OR customer_id <> $1), and = 0 does not match empty cells either.

3. Empty values first

Sort by customer, highest first. PostgreSQL puts NULL values first in descending order and last in ascending order, so the first 243,007 rows of the "highest customer" view have no customer at all. That is 2,430 full blocks of blank cells before the first number. MySQL and SQLite do the opposite, so the same endpoint behaves differently on another database.

The grid's own sort puts empty values last in both directions. The package does the same on all four databases it supports.

4. Search: capital letters and wildcards

Type "heart" into the search box. The shop's catalogue is written in capital letters ("HEART OF WICKER SMALL"), and LIKE is case-sensitive in PostgreSQL, so the hand-written endpoint finds nothing. The package finds 99,653 lines:

Search for "50%" in the description column and the opposite happens: % is a wildcard in LIKE, so the endpoint returns 7,565 lines containing "50", such as "SET OF THREE 50'S GIFT WRAPS", and none of them contains "50%". The package escapes % and _, and compares text without case. For contains, it also treats the Turkish dotted and dotless i as the same letter, the same way the grid does in the browser.

5. The sort direction is SQL too

The endpoint above at least looks column ids up in a map (COL[...]), but it pastes s.direction into the query as it arrives. A request whose direction is asc, (SELECT 1 FROM pg_sleep(2)) made the database wait two seconds before answering (2,190 ms measured). Any expression can go where that pg_sleep is. Bound parameters protect values, not the parts of the query that are built as text.

The package treats the column map as its whitelist. A request naming any other column, such as price; DROP TABLE invoices, is refused with a 400 and the message Unknown column "price; DROP TABLE invoices" in sort.. The direction gets the same treatment: anything other than asc or desc is a 400 (Unknown sort direction "asc, (SELECT 1 FROM pg_sleep(2))" — use "asc" or "desc".), and neither is ever copied into the query.

The same endpoint, with the package

import { createSqlLoader, SqlRequestError } from '@kanunilabs/datagrid-server';

const invoices = createSqlLoader({
  dialect: 'postgres', // 'mysql' | 'sqlite' | 'mssql'
  from: 'invoices',
  key: 'id',
  columns: {
    // nullable: false = NOT NULL in the table, so the SQL needs no NULL handling for it
    id: { type: 'number', nullable: false },
    invoice: { type: 'string', nullable: false },
    stockCode: { sql: 'stock_code', type: 'string', nullable: false },
    description: 'string',
    quantity: { type: 'number', nullable: false },
    invoiceDate: { sql: 'invoice_date', type: 'date', nullable: false },
    price: { type: 'number', nullable: false },
    customerId: { sql: 'customer_id', type: 'number', searchable: false },
    country: { type: 'string', nullable: false },
  },
  query: (sql, params) => pool.query(sql, params).then((r) => r.rows),
});

app.get('/api/invoices', async (req, res) => {
  try {
    res.json(await invoices.handle(req.query));
  } catch (e) {
    res.status(e instanceof SqlRequestError ? 400 : 500).json({ error: String(e) });
  }
});

It has no dependencies and brings no database driver: you pass the function that runs a query. It answers the rows, the total that sizes the scrollbar, footer totals, and the distinct values for the header filter's checklist (the distinctValues: true in the page code above). The package's tests run a list of filters and searches, the edge cases above among them, through the grid's in-browser engine and through a real SQLite database, and compare the rows.

What it costs, and the indexes that pay it back

Getting those cases right makes some of the SQL longer, and longer SQL can stop using your indexes. To compare text without case, both sides of an = go through LOWER(REPLACE(...)), and a plain index on country cannot answer that expression, so PostgreSQL reads the whole table. Sorting stays cheap: on PostgreSQL the package puts empty values last with NULLS LAST, and for a column marked nullable: false it writes a plain ORDER BY invoice_date DESC, id, which the existing index on invoice_date serves. Search needs a different kind of index: LIKE '%heart%' cannot use an ordinary one at all, whoever writes the query.

These are the times for one block of 100 rows plus the count, as the grid asks for it. Each is the median of seven runs on 1,067,371 rows, with the config above. Compare the package's two columns with each other more than with the first: the hand-written endpoint runs its page and count one after the other and searches two columns, while the package runs them side by side and searches four.

Differences of 10 or 20 ms between runs are noise on a laptop; the rows that matter are the last two. The matching indexes come from the package itself. indexStatements takes the same object you pass to createSqlLoader and writes the CREATE INDEX statements for the expressions it queries with, for your migration:

import { indexStatements } from '@kanunilabs/datagrid-server';

for (const sql of indexStatements(config, { columns: ['country', 'invoiceDate'] })) await pool.query(sql);

For this config it wrote five: one on the folded country for =, and one per sort direction for each column, ending in id. Search needs a trigram index per searchable column, which you write yourself:

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX ON invoices USING gin
  ((LOWER(REPLACE(REPLACE(REPLACE(COALESCE(description, ''), 'İ', 'i'), 'ı', 'i'), 'I', 'i'))) gin_trgm_ops);

An expression index is used only when the query contains the same expression: the same functions with the same literals, in the same order. buildSqlPlan(request, config) returns the statements a request would run without running them; the expression to copy is in its page.sql.

These indexes are not small, so pass only the columns users really filter or sort by. Here the five from indexStatements came to 153 MB and the four trigram indexes to 101 MB, next to a table of 123 MB, and building all nine took 19 seconds. The country = index alone is 7 MB and does nearly all of the work in its row. The four sort indexes are most of the 153 MB and bought little on this table, because the plain index on invoice_date already served the sort; they matter on columns that have no index yet.

Limits

• Deep pages still cost more. OFFSET 1000000 makes the database step over a million rows: even with the matching index, the block at row 1,000,000 took 207 ms against 56 ms for the first. A grid lets the user drag the scrollbar to any row, so it cannot use keyset paging, which only works from one page to the next.

• Every block is counted. The total sizes the scrollbar, so the package runs COUNT(*) with the same filters next to every block it serves. Run on their own, the count of this table took about 45 ms and the first page about 1 ms, so the count is nearly all of a block's time when nothing is filtered.

• Some things are the database's to decide: the sort order of text (your collation), and on SQLite, upper and lower case beyond ASCII.

• Free and paid. The server package, loading from the server, sorting, filtering, search, distinct values and footer totals are all free. Grouping, a tree and exporting the whole result from the server need the paid grid on the page; the server side is the same package.

Try it

The server-side data guide has the full contract and the package's options for PostgreSQL, MySQL, SQLite and SQL Server. The sales dashboard demo loads the same 1,067,371 lines into the browser instead, if you want to compare.

Data: Online Retail II, UCI Machine Learning Repository (Chen, 2019), CC BY 4.0.

Disclosure: this article was drafted with AI assistance. Every number in it was measured against our packages (@kanunilabs/datagrid-react 1.8.0, @kanunilabs/datagrid-server 1.1.0), PostgreSQL 16 and the published dataset in October 2026.

This post builds that report once, so that the person reading it can make those changes themselves. The data is real: the 1,067,371 invoice lines of the Online Retail II dataset, a UK online gift shop's sales from December 2009 to December 2011, with invoice number, product, quantity, unit price, customer and country on every line. The table is our free PivotGrid for React, and everything below is in its Community edition.

Here is the finished report: the eight countries with the most revenue in 2011, inside each one its five best-selling products, with units sold, the average price paid and each line's share of the year.

It is live at /demos/pivot-report. The sections below take it apart in the order it was built: the fields, the best sellers, two numbers the raw data gets wrong, the share column, saved views, and the invoice lines behind a cell.

The fields

A pivot table is configured as a list of fields. Each one names a column of your data, an area (rows, columns, values or the filter area) and how to show it:

import { BasePivotGrid, type PivotField } from '@kanunilabs/pivotgrid-react';
import '@kanunilabs/pivotgrid-react/styles.css';

const fields: PivotField<Line>[] = [
  { id: 'country', dataField: 'country', caption: 'Country', dataType: 'string',
    area: 'row', areaIndex: 0, sortOrder: 'desc', sortBySummaryField: 'revenue', topN: 8 },
  { id: 'product', dataField: 'description', caption: 'Product', dataType: 'string',
    area: 'row', areaIndex: 1, sortOrder: 'desc', sortBySummaryField: 'revenue', topN: 5 },
  { id: 'revenue', dataField: 'revenue', caption: 'Revenue', dataType: 'number',
    area: 'data', areaIndex: 0, summaryType: 'sum' },
  { id: 'units', dataField: 'quantity', caption: 'Units', dataType: 'number',
    area: 'data', areaIndex: 1, summaryType: 'sum' },
  { id: 'year', dataField: 'year', caption: 'Year', dataType: 'string',
    area: 'filter', filterValues: new Set(['2011']), filterType: 'include' },
];

<BasePivotGrid gridId="sales-report" data={lines} initialFields={fields}
  layout={{ rowHeaderLayout: 'tree' }} />;

Everything set here is also on screen. The year filter is a chip in the filter area with a filter icon on it; the sort is an arrow on the Country and Product chips. A user who wants 2010 opens the Year filter and ticks it, without anyone editing the field list.

Best sellers per country

sortBySummaryField: 'revenue' orders countries by their revenue instead of alphabetically, and topN: 8 keeps the first eight. The same two options on Product apply inside each country, so every country gets its own top five, not the shop's overall top five.

The cut changes what is listed, not what is counted. The grand total at the bottom is still the whole year, every country included: £9,032,994. The United Kingdom alone is 84.2% of it.

Postage is the UK's best seller

The first version of this report put DOTCOM POSTAGE at the top of the United Kingdom, ahead of every product. Germany had POSTAGE and Manual in its top five, Ireland Manual and CARRIAGE.

The dataset mixes products with everything else that goes through an invoice: postage, carriage, marketplace fees, bad-debt write-offs, bank charges, manual adjustments. Ten descriptions in all. A best-seller report should not count them at all, so they are removed with a prefilter, a condition applied to the source rows before anything is grouped or summed:

const NOT_PRODUCTS = ['DOTCOM POSTAGE', 'POSTAGE', 'CARRIAGE', 'AMAZON FEE', 'Adjust bad debt',
                      'Manual', 'Bank Charges', 'Discount', 'CRUK Commission', 'SAMPLES'];

<BasePivotGrid /* … */ layout={{
  rowHeaderLayout: 'tree',
  prefilter: { logicalOperator: 'and',
               conditions: [{ fieldId: 'product', operator: 'notin', value: NOT_PRODUCTS }] },
}} />

Because it runs before aggregation, it changes the totals too: the year's grand total is product revenue, not product revenue plus postage minus fees.

A cancelled order in the top five

With postage gone, the next surprise was PAPER CRAFT, LITTLE BIRDIE: £168,470 and 80,995 units, the UK's best seller of 2011. One customer ordered 80,995 paper birds at 06:15 on 9 December 2011 and cancelled the order twelve minutes later.

Whether it shows up depends on one filter, the one on the Kind chip. The demo gives every line a Kind, read from its invoice number: a sale, a cancellation (numbers starting with C) or an adjustment (starting with A). Filter Kind to Sale and you are adding up orders, including the ones that were taken back; the paper birds win. Leave Kind unfiltered and cancellations subtract from the products they cancel; the paper birds net to £0 and drop out, and Regency Cakestand leads with £109,044.

The report uses net revenue. The Kind chip stays in the filter area, so anyone who needs gross sales can switch.

Average price is computed after the sum

The average price column is the one that is easiest to get wrong. Put the unit price in the values with summaryType: 'avg' and you get the average of the line prices: for Regency Cakestand in the UK, £14.07. But a line for one cake stand and a line for 192 count the same in that average. What customers actually paid per unit is revenue divided by units, £12.83, because the large orders were the cheaper ones.

That ratio has to be computed per cell, after revenue and units are summed. A summary-level calculated field does exactly that:

import { compileSafeFormula } from '@kanunilabs/pivotgrid-core';

const AVG = '[Revenue] / [Units]';
const avgPrice: PivotField<Line> = {
  id: 'avgPrice', caption: 'Avg price', dataType: 'number', area: 'data', areaIndex: 2,
  isCalculated: true, formulaType: 'summary', formulaString: AVG,
  calculateSummaryExpression: compileSafeFormula(AVG, new Map([['Revenue', 'revenue'], ['Units', 'units']]))!,
};

The formula language is deliberately small, field references, numbers and arithmetic, and it is compiled without eval, so a formula can come from a saved report without running code. Computed row by row instead, the same formula would divide each line and then add the quotients, which is a number with no meaning.

Share of the year

The last column is revenue again, shown as a percentage of the column total:

{ id: 'share', dataField: 'revenue', caption: 'Share of year', dataType: 'number',
  area: 'data', areaIndex: 3, summaryType: 'sum', summaryDisplayMode: 'percentOfColumnTotal' }

Users can make the same change without code: right-click a value chip, open Field Settings, and pick % of total, of row or of column, a running total, or the difference or % difference from the previous value.

Let users keep their version

Once users can rearrange a report, they will want to keep what they built. The Views menu in the footer saves the current fields and layout under a name, loads it back, updates it, and can set it as the default that opens next time. The grid also remembers its last state per gridId across reloads.

By default this lives in the browser's localStorage, so a view saved on one laptop is not on the next one. To keep views per user on your server, pass stateStoring={{ enabled: true, type: 'custom', onSave, onLoad }} and store the state object yourself.

Click a number, see the lines

The question after "what are the numbers" is "where does this one come from". Pass onCellClick and the grid hands you the source rows behind the clicked cell:

<BasePivotGrid
  /* … */
  onCellClick={(e) => {
    if (e.cellType === 'rowHeader' || e.cellType === 'colHeader') return;
    showLines(e.records ?? []);
  }}
/>

What you render is up to you. The demo lists the 50 largest lines and adds them up next to the cell's value. For Regency Cakestand in the UK that is 1,686 invoice lines summing to £109,044, the same figure the cell shows.

That lookup has a cost worth knowing. The grid does not keep the rows behind each cell; when the handler reads e.records, it finds them again, on the main thread, matching the cell's row and column path first and applying the filters only to those rows. Finding these 1,686 lines among a million took 43–93 ms in our browser. The cost follows the number of rows behind the cell: the United Kingdom's total, 453,888 lines, took 363–529 ms (that includes the demo sorting them). Fine for a click, but it is time the page cannot respond. A handler that never reads records pays nothing.

How fast is the rest

Every change to this report regroups all 1,067,371 rows. The aggregation runs in a Web Worker, off the thread that handles clicks and typing; on the live demo a recompute of this layout took 83–222 ms over five runs, most of them under 120. Our previous post measures that in detail, including the longest pause it causes on the page.

Limits

• The data has to be in the browser. The demo downloads a 5.5 MB file once and decodes it into a million row objects. For data that should stay on the server, the paid edition can ask your server for the aggregates instead.

• Reading a cell's records runs on the main thread: tens of milliseconds for a product, around half a second for a whole country, as measured above.

• No "Others" row in this report. The top-N options can fold the cut countries and products into an "Other countries" row (topNShowOthers); this report leaves it off. Writing this post we found two bugs in it (under a second top-N level the outer Others row stayed empty, and a calculated ratio was added up instead of recomputed); both are fixed in PivotGrid 1.9.0.

• Paid parts. The formula designer that lets end users write calculated fields, a ready-made drill-down window, rendered charts and styled Excel/PDF export are in the paid edition. Everything in this report is free.

Try it

The report is at /demos/pivot-report: drag Month into the columns, untick a country in its filter, click any value. The PivotGrid docs cover fields, top-N, calculated fields, display modes and saved views for React and plain JavaScript.

Data: Online Retail II, UCI Machine Learning Repository (Chen, 2019), CC BY 4.0.

Disclosure: this article was drafted with AI assistance. The demo and every number in it were measured against our packages and the published dataset in October 2026.

The catch is the data. Every drag regroups and re-sums every row. With a few thousand rows nobody notices. With a million, the obvious implementation freezes the page while it works, and a page that freezes on every drag is a page people stop dragging in.

This post measures that on real data: the 1,067,371 invoice lines of the Online Retail II dataset, pivoted in the browser with our free PivotGrid. The demo times every recompute in your own browser, so you can check each number here against your machine.

The report a user builds

Start from revenue by country and year, then drag Month into the columns or Product into the rows. Each drop recomputes the whole table:

In React that is one component and a list of fields; area says where each field starts, and the user moves them from there:

import { BasePivotGrid } from '@kanunilabs/pivotgrid-react';
import '@kanunilabs/pivotgrid-react/styles.css';

const fields = [
  { id: 'country', dataField: 'country', caption: 'Country', dataType: 'string', area: 'row' },
  { id: 'year', dataField: 'year', caption: 'Year', dataType: 'string', area: 'column' },
  { id: 'revenue', dataField: 'revenue', caption: 'Revenue', dataType: 'number', area: 'data', summaryType: 'sum' },
  { id: 'month', dataField: 'month', caption: 'Month', dataType: 'string', area: 'filter' },  // waiting to be dragged
  { id: 'product', dataField: 'description', caption: 'Product', dataType: 'string', area: 'filter' },
];

<BasePivotGrid gridId="sales" data={rows} initialFields={fields} />;

What a drag costs

The demo measures two things on every recompute:

• How long it takes, from the moment the pivot starts to the moment the new table is painted.

• The longest pause on the page's main thread in that window. The browser's Long Tasks API reports every task of 50 ms or more, and the main thread is the one that also handles your clicks and keys. Rendering the new table counts too.

For country by year, or sales against cancellations by country, a recompute took 29 to 48 ms and no task on the main thread reached 50 ms. Drag Month into the columns and Year out, about 40 countries by 25 months, and it took 45 to 82 ms over three runs, with the longest pause between none and 54 ms:

The grouping and summing run in a Web Worker, a second thread the page starts for the pivot. The main thread only receives the finished totals and draws them.

The obvious way, measured

To see what the worker buys, the demo has a button that computes the same country-by-year revenue the way a quick implementation would: one pass over every row with a Map, on the main thread.

const totals = new Map<string, number>();
for (const r of rows) {
  const key = `${r.country}|${r.year}`;
  totals.set(key, (totals.get(key) ?? 0) + r.revenue);
}

That loop froze the page for about 110 ms, longer than the pivot's whole recompute. Its totals are the same as the pivot's: £7,511,064 for the United Kingdom in 2011 and £134,790 for France in 2010, which we also checked with an independent computation over the source file.

A tenth of a second does not sound like much until you type through it. The demo has a text box for that: type while you drag fields, and the letters keep appearing; type while the loop runs, and they arrive all at once when it ends.

The worker does not make the work free. It moves it off the thread that answers the user.

Where the page stopped, and the fix it led to

Put Product in the rows and Month in the columns, about 5,000 products by 25 months, sorted by name, and the measurement changed: on October 7 the recompute took 350 to 650 ms and the main thread paused for 290 to 510 ms.

The aggregation was still in the worker, so we looked at what was left on the main thread. Sorting the same table by revenue instead of by name cut the pause to 105 to 183 ms. The difference was how the 5,000 product names were compared:

// what the pivot's sort did before 1.7.2
names.sort((a, b) => a.localeCompare(b, locale, { numeric: true }));

// the same order, with the collator built once
const collator = new Intl.Collator(locale, { numeric: true });
names.sort(collator.compare);

Both give the same order. On 5,000 names, about 60,000 comparisons, the first took 206 to 226 ms and the second 4 to 5 ms, on the same machine. Called with an options object, localeCompare sets up its comparison rules again on every call; a collator sets them up once.

We shipped the second version in PivotGrid 1.7.2 on October 8 (@kanunilabs/pivotgrid-react 1.4.2). Measured again in the live demo, five loads each, the layout sorted by name now takes 151 to 196 ms with a longest pause of 97 to 118 ms, the same as sorted by revenue. You can check it at /demos/pivot?layout=product-month&sort=name.

If you sort strings anywhere a user waits, a table header, a filter list, a dropdown, this one is worth checking in your own code.

The remaining 100 or so milliseconds were in the React grid, not in the pivot. After the first paint it measured the panel widths and header heights and kept them in React state, so the roughly 1,400 visible cells were drawn a second time in the same task, only to change two paddings and a few CSS variables. It also wrote the row-header width variables on the grid's outer box, where every cell inherits them, so each write invalidated the style of every cell and the next measurement forced a full style recalculation. Now the measurements go through refs and the variables sit only on the panel that reads them. On a local production build of this demo, ten switches to Product × Month, the median longest pause went from 89 to 51 ms and the recompute from 155 to 102 ms. That fix shipped in @kanunilabs/pivotgrid-react 1.5.0 on October 9.

Measure your own pivot

You do not need our component to get these two numbers. Any pivot or table that recomputes on user input can be measured the same way:

const longTasks: PerformanceEntry[] = [];
new PerformanceObserver((list) => longTasks.push(...list.getEntries()))
  .observe({ type: 'longtask', buffered: true });

const t0 = performance.now();
await recompute();                       // whatever your table does on a drag
requestAnimationFrame(() => requestAnimationFrame(() => {
  const t1 = performance.now();          // the new table has been painted
  const pause = Math.max(0, ...longTasks
    .filter((t) => t.startTime + t.duration >= t0 && t.startTime <= t1)
    .map((t) => t.duration));
  console.log(`recompute ${t1 - t0} ms, longest main-thread pause ${pause} ms`);
}));

If the second number is large, your users feel it, whatever the first one says.

What this costs

• It is free. Drag and drop, filters, sorting, % of totals and saved views are in the Community package, with no licence key and no watermark. Calculated fields in code and the rows behind a clicked cell are free too; the formula designer for end users, rendered charts, the ready-made drill-down window and styled Excel/PDF export are in the paid edition.

• The data has to be in the browser. The demo downloads a 5.5 MB file once and decodes it into a million row objects before the first pivot. For data that should stay on the server, the paid edition can ask your server for the aggregates instead.

• Wide layouts still pause the page. For 5,000 products by 25 months, after the two fixes above, the median longest pause was 51 ms on our local production build; slower machines see more. The panel in the demo shows what yours does.

Try it

The demo is at /demos/pivot; /demos/pivot?layout=product-month opens the wide layout, best sellers first, and adding &sort=name sorts it by name. The PivotGrid docs cover fields, filters, summary types and the React and plain JavaScript setups.

Data: Online Retail II, UCI Machine Learning Repository (Chen, 2019), CC BY 4.0.

Disclosure: this article was drafted with AI assistance. The demo and every number in it were measured against our packages and the published dataset in October 2026.