How can I trigger processRowUpdate to persist row deletion in Material UI DataGrid?

The short answer is: processRowUpdate isn’t triggered for delete actions unless the row is in edit mode. The DataGrid’s design is that processRowUpdate fires when a row exits edit mode. In the CRUD example the delete action bypasses any editing cycle and simply removes the row from state.

If you want to persist the deletion on the server via processRowUpdate, you’ll need to simulate an edit cycle so that processRowUpdate is triggered. Here are two approaches you might consider:

---

1. Simulate Edit Mode for Deletion

Before deleting, switch the row into edit mode, update it with a “delete” flag, and then exit edit mode. For example:

TYPESCRIPTCopied
// Step 1: Switch row into edit mode
const handleDeleteClick = (id: GridRowId) => async () => {
  // Set the row in edit mode
  setRowModesModel({ ...rowModesModel, [id]: { mode: GridRowModes.Edit } });

  // Optionally update the row to add a deletion flag
  setRows((prevRows) =>
    prevRows.map((row) =>
      row.id === id ? { ...row, _action: 'delete' } : row
    )
  );

  // Step 2: Then programmatically stop edit mode so that processRowUpdate is triggered
  // If using apiRef:
  apiRef.current.stopRowEditMode({ id });
};

When you call stopRowEditMode, the DataGrid will trigger processRowUpdate. In your processRowUpdate callback, check for the deletion flag and perform your server-side deletion.

TYPESCRIPTCopied
<DataGrid
  {...otherProps}
  processRowUpdate={(updatedRow, originalRow) => {
    if (updatedRow._action === 'delete') {
      // Perform your deletion API call here
      // On success, return the updated row or remove the row from state elsewhere
      return updatedRow;
    }
    return updatedRow;
  }}
/>

---

2. Handle Deletion Outside of processRowUpdate

If simulating edit mode feels too contrived for deletion, you could handle the server-side deletion separately from the grid’s editing logic. For instance:

TYPESCRIPTCopied
const handleDeleteClick = (id: GridRowId) => async () => {
  // Optionally get the row information before deletion
  const rowToDelete = rows.find((row) => row.id === id);
  
  try {
    // Call your API to delete the row on the server
    await deleteRowOnServer(rowToDelete);
    
    // On success, update local state
    setRows((prevRows) => prevRows.filter((row) => row.id !== id));
  } catch (error) {
    console.error('Failed to delete row', error);
    // Optionally display an error message
  }
};

This approach keeps deletion separate and avoids having to simulate an edit cycle.

---

Summary

• Why processRowUpdate isn’t called: Because it’s only triggered when a row exits edit mode.
• How to trigger it for deletions: Either simulate editing by switching to edit mode, updating the row (e.g., adding a deletion flag), and then exiting edit mode to trigger processRowUpdate, or handle the deletion outside the editing lifecycle.
• Recommendation: In many cases, handling deletion outside processRowUpdate (option 2) is cleaner unless you have a unified save mechanism that must cover create, update, and delete.

Choose the method that best fits your application’s architecture and desired user experience.