Cell Editing

One column per built-in editor. text is the default, so a column that only sets editable: true gets it without naming it:

• 'text' — auto-focused and pre-selected, so typing replaces.
• 'number' — the committed value is cast to a number, not left as a string. editorOptions carries min, max and step.
• 'date' — a calendar; commits an ISO date string (2021-03-15) while showing a readable one (Mar 15, 2021). Give the column a matching valueFormatter or the value appears to change as the editor opens — editor says how a column is edited, never how it is displayed.
• 'select' — needs editorOptions.options.
• 'checkbox' — commits the moment it is toggled. There is nothing to press Enter on, and Escape has nothing to restore.
• A TemplateRef — the Role column. Anything you can render, with commit(value) and cancel() handed to you.

ID declares no editable, so double-clicking it does nothing at all — read-only is the default, not something to switch on.

Two more editors, on a licence

'large-text' (a popup textarea) and 'rich-select' (a searchable list with custom option rendering) are built in too. They are the one part of editing that is not free — set either without a licence and the cell edits as plain text instead.

editable accepts a function, evaluated per row:

{ key: 'salary', prop: 'salary', editor: 'number',
  editable: (row) => row.active }

The four rows marked Active can be edited; the rest cannot. The grid asks before it offers, so a locked cell never opens an editor — there is no rejected commit to explain and no error state to design. It shows in the DOM as well as on screen: an editable cell carries gc-cell--editable, and a locked one does not.

Active itself stays editable on every row, deliberately. Locking the switch that unlocks the row is a trap worth avoiding: toggle a row on and its Name and Salary become editable immediately, because the function is re-evaluated, not cached.

Reading a nested field costs nothing — prop: 'location.city' is a dot path and the grid walks it. Writing one is different: the default write is a shallow spread, { ...row, ['location.city']: value }, which creates a stray top-level key and leaves the real field untouched.

valueSetter: (row, value) => ({
  ...row,
  location: { ...row.location, city: String(value) },
})

Both columns above show the same field. Edit City and it changes. Edit City (no setter) and it snaps back — the write happened, just not where anyone was looking. That column is on the page precisely so the failure is visible once instead of surprising you later.

Return a new object

The setter must return a new row, not a mutated one. The grid compares references to decide what to repaint, so mutating row in place writes the value and paints nothing — the same symptom as having no setter at all, from the opposite cause.