bc-grid
GitHub

Bulk row actions

View source

Render an action toolbar above the grid as soon as one or more rows are selected. Wire the actions to applyRowPatches and ship inverse patches with showUndo for free Cmd+Z-style toast undo.

Order #
Customer
Sales rep
Status
Amount
R-000001
Customer 00001
Avery Chen
active
$0.00
R-000002
Customer 00002
Ben Singh
pending
$31.42
R-000003
Customer 00003
Cara Diaz
closed
$62.83
R-000004
Customer 00004
Drew Lin
active
$94.25
R-000005
Customer 00005
Elena Park
pending
$125.66
R-000006
Customer 00006
Felix Roy
closed
$157.08
R-000007
Customer 00007
Gita Bose
active
$188.50
R-000008
Customer 00008
Henry Kao
pending
$219.91
R-000009
Customer 00009
Avery Chen
closed
$251.33
R-000010
Customer 00010
Ben Singh
active
$282.74
R-000011
Customer 00011
Cara Diaz
pending
$314.16
R-000012
Customer 00012
Drew Lin
closed
$345.57
R-000013
Customer 00013
Elena Park
active
$376.99
R-000014
Customer 00014
Felix Roy
pending
$408.41
R-000015
Customer 00015
Gita Bose
closed
$439.82

Try this

Tick checkboxes on the left, then use the toolbar that appears above the grid.

  • Tick 3 rows. The toolbar shows count + actions.
  • Click Mark closed — all 3 update at once. An undo toast appears for ~5s.
  • Click Undo on the toast — the 3 rows revert to their original status.
  • Tick rows from different pages (toggle the master checkbox in the header) — the action operates on the entire selected set.

The contract

  • checkboxSelection. Pass checkboxSelection to mount the selection column.
  • bulkActions. A render prop that receives a BcBulkActionsContext with { selectedRowIds, selectedRowCount, clearSelection, showUndo }. Returns React. Mounted automatically when there's at least one selection.
  • apiRef.current?.applyRowPatches. Apply many row updates atomically. Each patch is { rowId, fields }. Updates flow through the same commit pipeline as cell edits; consumers can mirror to the server in one batch.
  • showUndo. ctx.showUndo({ label, inversePatches }) mounts an Undo toast. Click Undo and the inverse patches flow back through the same pipeline. Toast auto-dismisses after the user-tunable timeout.

Why inverse patches

Storing inverse patches in the toast (rather than rolling back via a separate API) keeps undo decoupled from the data source. The consumer's applyRowPatches handler runs the same code for both the forward action and the undo. No bespoke "undo handler" to write per action. Clean for ERP audit-log writes too — both the forward and the undo entry point go through the same hook.