searchCols and stateSave issue

JammySlayer

I've got a page that I'm setting a search column in via SearchCols dynamically, I'm also using stateSave, issue is that after the initial load, it saves the state and doesn't accept a change to the SearchCols should I then reenter the page with the expectation of SearchCols using a different value.

If you change the following to have stateSave true, it appears to have the initial state of blank stuck, rather than allowing the new SearchCols to take effect.
http://live.datatables.net/wisamowo/1/

Only way I've found around this is either to clear state if the dynamic search has been changed, or to do a call back on initComplete, which then leads to double loading/slowness, there a better way of doing it, was toying with the idea of updating the state, so when it loads the state, it'll have the new dynamic search value in the state, but doesn't feel like the cleanest solution.

colin

Hi JammySlayer,

It seems the searchCols is performed first, and is then those values are being over-written by the stateLoad. I'm not sure why the stateSave isn't storing that value, but this may be a workaround - it overwrites the searchCols value back into the loaded data, meaning it remains.

Please let us know if this does the trick,

Cheers,

Colin

allan

Any values saved by the state saving will override the initialisation parameters. DataTables doesn't also store the initialisation parameters in the state to check if they have changed - that seems like too much overhead for the benefit it would provide.

If you want to enable state saving, but have it not save certain parameters you can use stateSaveParams to delete the parameters that you don't want from the state object to save.

Regards,
Allan

JammySlayer

That would of been a valid solution if I wasn't already doing some default stuff with stateSaveParams, I could have extended it but wasn't looking particularly elegant

I've opted to just do

$("#" + tableId).DataTable().state.clear().destroy();

In an if block dependant on whether it's for the entry with an expectation of the reset to a particular status, it's not ideal due to the potential navigation from the table, to a next page, then backing will then cause the reset again, but it's best solution I can see at the moment.