any news regarding this issue?
No sorry. I'll post back when i've had a chance to look int it - but there are other things I'm currently working on first i'm afraid. Did I understand correctly that you have a workaround for the issue at the moment.
it's not a good workaround, because when the datatable shows it is duplicated (there is the actual datatable and another empty one) and the users don't appreciate it.
great news, this article solved our problem
Instead of the code we had.
Yishay: how did it solve your issue?
I'm having exactly the same TypeError: s.nTHead is null error
On this line in datatables:
TypeError: s.nTHead is null
if ( s.nTable == this || s.nTHead.parentNode == this || (s.nTFoot && s.nTFoot.parentNode == this) )
I don't get why it wouldn't hurt to check if s.nTHead is not null, as is done for s.nTFoot...
OK, I found the culprit, it's a breaking change in 6f2fe9343d59cb97b946c3b6401df3f141708dd5 that made its way in when I updated my dependencies. The backward compatibility is, unfortunately, not working 100%. The doc say: "If the data is loaded synchronously the return value should be the loaded state (or null if no data was loaded).", unfortunately my stateLoadCallback was returning undefined before, and that didn't trigger issues. With that new commit, it needs to return null to keep working; returning undefined put it in a state corrupted enough (?) that it hit the line above with s.nTHead being null.
Interesting - thank you for letting me know about that. So to confirm, with a different return from the stateLoadCallback you've got it up and running again?
It looks like you're new here. If you want to get involved, click one of these buttons!
DataTables designed and created by SpryMedia Ltd.
SpryMedia Ltd is registered in Scotland, company no. SC456502.