Cannot read property parentNode of null

yishayh

Hi Allan,

any news regarding this issue?

Thanks,
Yishay

allan

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.

Allan

yishayh

Hi Allan,

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.

Yishay

yishayh

Hi Allan,

great news, this article solved our problem
We used

$($.fn.dataTable.tables(true)).DataTable().columns.adjust();

Instead of the code we had.
Many thanks,
Yishay

sebastienbarre

Yishay: how did it solve your issue?
I'm having exactly the same TypeError: s.nTHead is null error
On this line in datatables:

if ( s.nTable == this || s.nTHead.parentNode == this || (s.nTFoot && s.nTFoot.parentNode == this) )

sebastienbarre

I don't get why it wouldn't hurt to check if s.nTHead is not null, as is done for s.nTFoot...

sebastienbarre

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.

allan

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?

Allan