Value Getters & Formatters

When you need one

Reach for valueGetter when the column has no field to point at. Full Name is built from two fields; Years is arithmetic on a third. Neither exists on the row, and neither needs to.

{
  key: 'fullName', name: 'Full Name',
  valueGetter: row => `${row.firstName} ${row.lastName}`,
  sortable: true, filter: { type: 'text' },
}

A getter replaces prop. Set both and the getter wins, so delete the prop rather than leaving it there to be read later as if it mattered.

It is a real column

Because the getter produces the value itself, everything downstream sees it. Sort Full Name and the rows order by "Alice Smith". Type into its filter and the search runs over the same text. Sort Years and the order is numeric, because the getter returned a number and nothing has turned it into a string yet.

Display only — and that is the point

Salary reads as $92,000. Sort it: the order is numeric, not alphabetical. Its filter is a number box, so you type 92000 — the value, never the text. Double-click a cell: the editor opens on 92000 too.

That is the whole rule in one column. A grid that formatted before it sorted would put $1,000 before $90, which is the classic version of this bug.

Two boxes, one column, two different answers

Started shows Jan 2016 and stores 2016-01-10. Both boxes below take text, so nothing but the value they read separates them:

• Type Jan 2016 into the column filter under Started — no rows. It compares against the stored date.
• Type Jan 2016 into the quick-filter box above the grid — the rows appear. It searches what is on screen.

That is deliberate rather than an inconsistency: someone typing into a search box is copying what they can see, while a column filter is a comparison against the real value. Type 2016-01 into the column filter and it matches.

Keep them pure and cheap

A formatter runs for every visible cell on every render. Build the Intl.NumberFormat once outside the column definition, not inside the function. And do not read anything that can change underneath it — a formatter that reaches for the clock will disagree with itself between two renders. Years above is measured against a fixed date for exactly that reason.

A formatter that throws does not take the grid down: the cell falls back to the raw value, and one warning is logged for the column rather than one per cell.

Reading is free, writing is not

prop: 'contact.email' reads the nested field with no code at all — the cells above are proof. Writing is where it breaks. The default write is a shallow set on prop, so committing an edit would put the string where the contact object used to be.

valueSetter: (row, value) => ({
  ...row,
  contact: { ...row.contact, email: String(value) },
})

The setter returns a new row. That is what keeps the change visible to everything watching, and it is why the row is spread rather than mutated.

Most columns need no setter

Department above is editable and has no valueSetter. It does not need one: the field sits at the top level, so the default shallow write is already correct. Add a setter when the default would be wrong — which in practice means anything nested, or a value that has to be parsed before it is stored.

cellEditCommit hands you the row the setter returned, so the object you send to your API is the one the grid is showing.