Confirmation when deleting datatable row

Hey,

i have a Dash data table where rows can be deleted. I’d like to have some sort of warning when a users tries to delete a row. I saw I can use a Confirm Dialog, the problem is setting up the callbacks.
I already have a large callback with several inputs and the data table’s data as output. This callback deals with all editing of the table (it updates a backend DB), including row deletion. When a user deletes a row this “editing” callback is triggered. I can have this callback display the confirm dialog, but then I would need to re- trigger the “editing” callback to perform the deletion - but this time I won’t have the data needed to perform the action.

Any ideas would be greatly appreciated :slight_smile:

Hello @amihaio,

When I work with databases and a front end, I actually make a change log instead of taking their actions directly.

I also give them the ability to reapply the old value. That way the can undo their changes if necessary.

Then when the user is ready, they click save, which pushes the change log to get parsed for the updates.

I understand not wanting to do things this way due to ease.

How exactly do you trigger the delete action? Is it just based upon the data changing?

Thanks for the quick reply!

Actually the change log sounds like an interesting idea (I was wondering how I would implement an undo function).
Do you mind elaborating on how you implement this?
The change log is a file on disk?
Does this mean you don’t use the edit ability of the data table, rather you have an “update table” modal or something of the like? Then this modal collects the intended changes and pushes them to another components that performs the update in the backend?

Regarding the current implementation, the Dash data table has the a native ability to delete rows, which changes the data property of the table and this is what triggers a callback that updates the backend DB.

Sure.

I use the edit functions of the table as well, but when the data_timestamp changes, I compare the old version (data_previous) to the new version (data) and pull out the changes. I place the rows key, column, old value and new value into a separate table.

On the second table, when you delete a row it reverts the change to the original table.

For my row ids, all of my tables have unique identifiers or combos in order to create distinct matches.

I haven’t messed with deleting rows, but you’d still know that the row doesn’t exist in the new data.

I like doing this all on the clientside to make sure the changes are quick. Lol.

Thanks for the info
I started implementing a change list as you mention, seems like the right thing to do for many reasons.
Still though, the solution for initial problem seems extremely hacky and not scalable. I’ll describe the situation again since I don’t think it was clear at first.

Since an output can appear in only one callback, I have a main callback that takes as input all things that can change the table and have the table’s data prop as output. This works fine as long as you don’t need to move to another callback in the middle, as is the case for want a warning dialog. In this case I can trigger the dialog from the main callback, but then need to go back to the main callback to be able to output the data. This means that for each such element (e.g. warning dialog) I want to trigger before making the update to the table I need to create a hidden div as output of the warning’s callback and input to the main callback. (I hope this is better described now).
If you have any ideas on how to do this better I’d greatly appreciate it :slight_smile:

P.S.
If there is a way to update a table without a dash callback that can also solve the problem

1 Like

@amihaio,

What you can do is instead of allowing the data to delete the row, you can have an icon that is a red “x”, so it looks the same, but is actually a cell.

Then when that cell is clicked, you fire your confirmation text. If yes, then you remove that row from the tables data, and fire your db update in the background. :slight_smile: