Excessive use of fnDestroy()?

Excessive use of fnDestroy()?

yossarianyossarian Posts: 1Questions: 0Answers: 0
edited April 2014 in General
Hi everybody.
I have a django site showing more than one table, all with different data from different models in my DB.

The site is divided into different tabs (using the bootstrap nav-bar). Whenever a tab is clicked it hides all the unrelated divs, shows the clicked div, retrieves the data from my django view via AJAX, and then calls the .dataTable() function on that specific table. Pretty straight forward so far.

Each table needed a bit of different treatment, so in my JavaScript code I wrote a generic function that manages to handle all the different scenarios, and whenever a button in the navigation bar is clicked - I call that function and with the given data I create it the way I want.

But then if I click Tab 1, move to Tab 2 and back to Tab 1, I get an alert that the table has already been created (behind the scenes the div was simply hidden....)

What I did was, before the .dataTable() call, I make a .fnDestroy() call, and I end up with something like this -
[code]
//Function gets info on how to create that specific table as well
function createDataTable(tableId) {
$(tableId).dataTables();
}


$('#myBtn').click(function (e) {
$(tableId).fnDestroy();
createDataTable(tableId);
$(this).tab('show')
})
[/code]
How bad is this? Having this function mess with the DOM behind the scenes every time the user moves to another tab? Does this even matter? Is this a design flaw and I should rethink the way I retrieve the data from the server, or the way I build the datatables? Perhaps I should have a separate function for each table, even if I repeat myself?

Thanks

Replies

  • allanallan Posts: 63,498Questions: 1Answers: 10,470 Site admin
    Its not bad as such - its just a performance hit since manipulating the DOM is quite a slow process. The destroy is required since you can't change the configuration for an existing table without destroying it (you could pass bDestroy in as true, which basically does exactly the same thing - destroys the existing table and then creates a new one).

    Normally what I would use myself in this situation is a different table for each tab. But your way is also valid, its just a case of determining how bad the performance hit is and if you think it is acceptable for your site.

    Allan
This discussion has been closed.