Why does dataTable.destroy() trigger the "deselect" event?

halloei

Link to test case: https://jsfiddle.net/ay7hb0np/
Debugger code (debug.datatables.net): %
Error messages shown: %
Description of problem:
When a user navigates to another page in my single-page application, I'm destroying all DataTables. I now noticed a bug in my application that occurs when the user has still rows selected before doing that.

In the JSFiddle..
1. Click on the "Content" row to select it
2. Click on the "Destroy DataTable" button

In the developer console you will see following output:

Destroying dataTable...
"deselect" triggered!
Destroyed dataTable!

My application crashes here because my select/deselect event handler updates the buttons I created with the DataTables Buttons extension and the buttons are already destroyed when deselect is triggered.

Is it necessary that DataTables.destroy() triggers the deselect event? What would be the best way to fix my use case?

kthorngren

@allan will need to tell you why the rows are deselected. Try turning off the event handler before destroying, like this:
https://jsfiddle.net/jvn5bt9h/

Kevin

allan

This was the original bug report that caused that line to be added:

When calling destroy() on a DataTable it doesn't deselect rows (or at least remove their selected classes), causing a problem if you then reinitialise the table as rows appear to be selected when they in fact aren't.

Can you show me your Buttons' code? I'm wondering if Buttons needs a little extra protection in it to handle such a case.

Allan

halloei

Thank you for your replies. I've added a button to my JSFiddle: https://jsfiddle.net/kgyva5qw/

As you can see from the comment, I've got logic at this point which updates the button's tooltip (depending on the rows that are selected). However this fails, as in my case bootstrap.Tooltip.getInstance($button.parent().get(0)) will be null while the dataTable.destroy() is being executed.

allan

Ah - it is the tooltip code that is getting tripped up here. I presume if you move the commented out line into the if condition to make sure the button is present, then it would work without throwing any errors?

Allan

halloei

Yes, I've done exactly that yesterday to solve it quickly.

However, I wonder if the best solution for the original bug report is to call deselect on destroy(). I just did not expect the method to trigger such an event.
Maybe destroy() could remove the selected classes without triggering deselect? And if a user added additional code for selecting rows, he should ensure his data is properly tidied up by himself?

Thank you for your fast responses and work!

allan

I think that's a good call - thanks for the suggestion! I've committed that change and it will be in the nightly shortly.

Allan