demo D274
Confirm before delete, block a locked row
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()
The configuration
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.37.0/lattice-grid.min.css">
<script src="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.37.0/lattice-grid.min.js"></script>
<div id="grid" style="height: 540px"></div>
<script>
const locked = new Set(['3', '5']);
const grid = LatticeGrid.createGrid(document.getElementById('grid'), {
rowKey: 'id',
selection: 'multiple',
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' } },
],
rows,
});
// A delete waits on this handler before it lands. The handler is async and the
// grid awaits it, so nothing is removed until the question is answered. Return
// without preventing to allow it; call preventDefault(reason) to cancel.
grid.on('beforeDelete', async (e) => {
const ok = await askToConfirm('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 so it can be shown rather than swallowed.
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));
// The same before* handlers gate the board and schedule modules: a card drag
// or a bar move can be held and cancelled exactly this way.
</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.