Lattice Grid Buy a licence

demo D274

Confirm Before Delete: beforeDelete and beforeEdit in React

A delete waits on a confirm before it lands, and an edit on a locked row is refused with the reason shown

beforeDelete, beforeEdit, preventDefault()

This grid holds a delete until a confirm, and refuses an edit on a locked row with the reason shown. It puts a checkpoint in front of consequential changes, so an irreversible delete or a protected row cannot be changed by accident.

Building…
Loading a live grid…

This is the React version. The grid mounts through the createLatticeGrid adapter, which takes its configuration as ordinary props and hands back the live grid through a ref. The grid below is the same one every other tab runs.

The configuration

<link rel="stylesheet" href="https://cdn.latticegrid.dev/lattice-grid@1.107.0/lattice-grid.min.css">

<div id="app"></div>

<script type="module">
  import React from 'https://esm.sh/react@18';
  import { createRoot } from 'https://esm.sh/react-dom@18/client';
  import { createGrid } from 'https://cdn.latticegrid.dev/lattice-grid@1.107.0/lattice-grid.esm.min.js';
  import { createLatticeReact } from 'https://cdn.latticegrid.dev/lattice-grid@1.107.0/modules/react.esm.min.js';

  const { LatticeGrid } = createLatticeReact({ React, createGrid });
  const LOCKED = new Set(['3', '5']);

  const columns = [
    { field: 'part', title: 'Part', layout: { width: 150, pin: 'start' } },
    { field: 'line', title: 'Line', layout: { width: 110 } },
    { field: 'bore', title: 'Bore', type: 'number', format: { decimals: 2 }, edit: { enabled: true, editor: 'number' } },
    { field: 'qty', title: 'Qty', type: 'number', edit: { enabled: true, editor: 'number' } },
  ];
  const rows = [/* the parts: id, part, line, bore, qty */];

  function App() {
    const onGridReady = (grid) => {
      // A delete waits on this handler before it lands: async, and the grid
      // awaits it, so nothing is removed until the question is answered.
      grid.on('beforeDelete', async (e) => {
        const ok = await window.confirm('Delete the selected row?');
        if (!ok) e.preventDefault('the operator kept the row');
      });
      // An edit on a locked row is refused, with the reason carried on the
      // paired edit:cancelled event.
      grid.on('beforeEdit', (e) => {
        if (LOCKED.has(String(e.key))) e.preventDefault('this row is locked for editing');
      });
      grid.on('delete:cancelled', (e) => console.log('delete blocked:', e.reason));
      grid.on('edit:cancelled', (e) => console.log('edit refused:', e.reason));
    };

    return (
      <LatticeGrid rowKey="id" selection="multiple" columns={columns} rows={rows} onGridReady={onGridReady} style={{ height: '540px' }} />
    );
  }

  createRoot(document.getElementById('app')).render(<App />);
</script>

Ask before a delete lands, and refuse an edit you should not allow

Some changes are too consequential to apply the instant a user reaches for them. A delete that cannot be undone deserves a confirm, and a row that is locked for a reason should refuse an edit and say why. Lattice Grid gives you both without you having to intercept clicks or police the keyboard yourself: every change a person makes to the data raises a matching before-event first, and the grid holds the change until your handler decides. Return without objecting and it proceeds as normal. Call preventDefault and it is abandoned, with the reason you pass carried through to a paired cancellation event so you can show it. A handler may be asynchronous, and the grid waits for it, so a confirm dialog or a permission check upstream genuinely gates the write rather than racing it. This demo pairs the two before-events that matter most day to day: a beforeDelete handler that pops a confirm and cancels the delete unless the operator agrees, and a beforeEdit handler that turns away any edit to a locked row and surfaces the reason instead of swallowing it. Nothing is removed and nothing is overwritten until the guard has had its say, so the grid stays in step with the rules your application already enforces.

How do you confirm before deleting a row in a JavaScript data grid?

Register a beforeDelete handler with grid.on. Because the handler can be asynchronous and the grid awaits it, you can open a confirm dialog, wait for the answer, and call preventDefault when the operator declines; the row is then left untouched and a delete:cancelled event fires carrying your reason. Return without preventing and the delete goes ahead. The same pattern gates every user-driven change, so a locked row refuses edits through beforeEdit, a move can be vetoed through beforeRowMove, and the board and schedule modules take the identical before* handlers for a card drag or a bar move.

Related demos