.detach() versus .remove() on draw (_fnDraw)

DirceuNazareth

Hi folks...

I am using DataTable for a bit more than one year so far, and it has working great, really rocks...

So, I noticed the Draw method do a $.detach instead of $.remove, what In most case will not harm. But... in my case, It created a big memory leak.

Here is my user case. I have/had to update a table using ajax. So, once I received the data DT does the following snippet:

```"createdRow": function (row, data, dataIndex) {```
   ```var $row = $(row);```
   ```$row.data('itemData', data);```
```}```

So when the user clicks the row I present a dialog whit extra-information (that is available in the data of the row, but not visible in the columns).

It is working. But when the application runs more than 12 hours it crashed the browser (I tested with FF and Chrome). So, I have started to profile the results when I noticed the data object was not being collected by the garbage collector. After some investigation, I discovered some not active cells and rows referencing the data. They nodes were no more in the DOM, but still alive, because of the $.detach instead of $.remove.

Summarizing, I change the jquery.dataTables.js to $.remove, instead of $.detach, and solve this problem. I don't know if it was a design decision or not, but here is my question: Is it a better way to solve this problem? If the answer is no, should next version of DT uses $.remove instead of $.detach, I cannot see a valid user case for $.detach anyway. Sorry if I am being limited on my way of seen the implementation.

allan

Do you mean here? If so, then yes, that is absolutely fully intentional. Using remove would be an error there.

The reason for using detach there is that it is quite reasonable to attach an event to a row, page away from that row, then page back to it and expect the event to still be attached to the row. It would cause a lot of headache and boiler plate code if remove were used there.

So accepting that, the question is, why is your code leaking? Are you using server-side processing, or are you removing rows using the API? If you have a link to a test case that would be useful.

Allan

DirceuNazareth

Hi Allan,

Unfortunately it is a web-application packaged on a desktop software. So, I don't have a link.

I can see the reason of your implementation now, fair enough. I know that may not work for all the binds in the code, but I am binding my events in parents elements. For instance: $("div#datatable_wrapper").on("click","tr", function(){//do something});

I am not using the serve-side option (because I am doing sorting on client-side), but I am not clear the table out of the API. Those are my steps:

1) declare table is a DataTable and save the initialization on a variable in a proper namespace (e.g. centralJS.myDataTable).

2) I am listening the draw.dt event, I set 1 second time out and do a centralJS.myDataTable.ajax.reload("a function to return the scroll position", false)

I am using a request comparison mechanism to avoid execute ajax.reload many times while my last request is still pending.

Thank you for your time.

allan

That event listener shouldn't leak - its delegated and would only leak if the whole table was removed, not just individual rows. In your createdRow function shown above the $row.data('itemData', data); could leak if the row is removed form the table - which would happen with the ajax.reload method.

What I would suggest is that you listen for the preXhr event and remove any data (or static events should there be any) that is bound to elements in the table. The rows().nodes() method can be used to get all nodes in the row.

Regards,
Allan

p.s. Thanks for your answers in other threads - you've got a great understanding of DataTables

DirceuNazareth

No problem, answer some question is a good way to make me learn.
Thank you for the solution.