How can I exclude the # rows displayed from State Restore?

desperado

We want to allow States to load without changing the # rows displayed.

I thought "paging" would be the setting to turn off but that doesn't work.

Is it possible to disable # rows displayed from a saved state ?

I don't see one on the documentation page https://datatables.net/reference/option/stateRestore.saveState

rf1234

You can use "stateSaveParams" and / or "stateLoadParams".
https://datatables.net/reference/option/stateLoadParams

Take a look at the "data" object in your debugger. I think there is a length attribute: data.length

You should be able to manipulate that. Just experiment whether setting it to zero or deleting it works.

This might work:

stateLoadParams: function (settings, data) {
    if ( typeof data !== 'undefined' ) {
        if ( typeof data.length !== 'undefined') {
            delete data.length;
        }
    }
},

I have "stateLoadParams" in my $.fn.dataTable.defaults. You might not check for "undefined" if you have it in your individual data table configuration.

rf1234

Here is a fiddle: http://live.datatables.net/kusoposa/1/edit

I have set the loaded length to 12. And it works. The delete also works. Just play around with it a little.

colin

Yep, agreed, there are option to not save features, such as paging , so I think it's not unreasonable to not want to save the page length too. I've raised it internally (DD-2492 for my reference) and we'll report back here when there's an update.

In the meantime, @rf1234 's approach would be a solid workaround.

Cheers,

Colin

desperado

@colin my testing is finding that setting paging to false is not preventing the page from saving, restoring and affecting active. I have paging set to false and yet when I save state from the first page and then switch to page 2 the state becomes inactive. If I select the state it returns to page 1.

Do I understand what “paging” should affect and this test reveals it may not be working or am I misunderstanding?

I can build a test case if my understanding is correct. My code uses ajax for stateRestore so it might be broken only when using ajax like the other issue I have with the SearchBuilder integration.

rf1234

Not sure whether this helps at all with your issue regarding the return to page 1:

When reloading the data table using ajax.reload() the default behavior is to resetPaging. I find that annoying and always turn it off like this:

table.ajax.reload(null, false);

desperado

@rf1234 thanks however I am not reloading data I am switching states using StateRestore. The point is that state restore saves the current page and restores it. If I saved the state on page 5 it would return to page 5. But I don’t want to save the page and I thought setting paging=false in state restore config should disable that but it is not working in my instance. I am checking with @colin if I understand first before I create a test case to demonstrate.

rf1234

If I saved the state on page 5 it would return to page 5. But I don’t want to save the page and I thought setting paging=false in state restore config should disable that but it is not working in my instance.

Ok, you shouldn't have deleted "data.length", but "data.start". "data.length" is the saved page length if paging is turned on. "data.start" is the row the display of rows starts. If you delete "data.start" you start from the beginning. I guess that's what you want.

Here is the test case:
http://live.datatables.net/kusoposa/4/edit

You might as well not delete "data.start" but set it to zero. Same effect.
http://live.datatables.net/guwonupa/1/edit

desperado

@rf123 You are not understanding my issue. I am not trying your method at the moment because StateRestore has the paging option. I am trying to address the fact that it is not working. I appreciate your suggestion but I would like to help fix this issue with StateRestore rather than hack around it. I will likely try your idea in the mean time before StateRestore fixes the paging=false issue (again assuming I understand what it is supposed to be doing) and hopefully we add a numRows=false feature as well to ignore the number of displayed rows being saved in StateRestore. Please let @colin address this so I can determine if I need to create a test case or not.

kthorngren

I created a test case and setting paging: false with the stateRestore.saveState seems to work correctly.
http://live.datatables.net/mizovupe/1/edit

However it does seem that the settings you have for stateRestore.saveState when the state is created is persistent even though the stateRestore.saveState might be changed. New states created after changing stateRestore.saveState will pick up the new settings. Wonder if this is what you are seeing.

Kevin

desperado

@kthorngren
No unfortunately it happens when I create new state as well.
Let me build the Ajax test case and see if it only happens in ajax version.

colin

Thanks for the comments, @rf1234, but as @desperado said this is specific to the new StateRestore extension - it's handy to have workarounds with your methods, but it's good to tackle the issue in that extension too.

@desperado - I modified the Ajax example locally and inserted the code from the noPaging example, to give this:

        buttons:[
            'createState',
            {
                extend: 'savedStates',
                config: {
                    ajax: '../data/stateRestoreSave.php',
                    saveState: {
                        paging: false
                    }
                }
            }
        ]

and this was behaving as expected - order/filtering/etc was saved, but the pagination wasn't. Could you look at that, please, and see it helps, and if no joy, yep, please could you knock out a test case that demonstrates the issue as it does look to be behaving to me,

Colin

desperado

@colin @kthorngren

I find it doesn't work when using ajax. I think this is another example of behavior being different with ajax save vs browser save. I don't understand why this would happen I would think ajax vs browser is only about acquiring/saving the data and should not affect the logic but this is the second issue I have found that only fails when using ajax to store states.

Here try this example.
http://live.datatables.net/pibehila/1/edit?js,output

1) Switch to page 4
2) Save a State (State 1) Note that the State is now indicating it is active (Green)
3) Switch to page 2 Notice that the State is now indicating it is not active, since paging is set to false this should not happen
4) Load the Saved state Notice that the page returns to page 4, since paging is set to false this should not happen

desperado

@rf123 Your solution sort of works but it causes several problems.

I did the following

stateLoadParams: function (settings, data) {
                delete data.length;
                delete data.start;
            },

State Restore now does not remember the page or the number of rows (length). That's good.

The problems are as follows
1) State Restore does not recognize the state as active unless you are on the same page that you were on when you saved the state.
2) Page length is no longer remaining when you refresh the page. That makes sense because we are removing length on load. But that means a user that prefers to see more data then the default, has to keep switching the page length every time they reload the data.

So unfortunately the solution doesn't work.

kthorngren

I'm not sure about step 3 and what should or shouldn't indicate as active

I followed your steps and paging: false seems to work correctly. I go to page 4, update the state for State 1, go to page 2 then select State 1 it goes to page 1.

Kevin

kthorngren

Just to prove that the process is working I added a step 0 of changing the sorting to make sure its restored. After updating State 1 I changed the sorting again. The sorting restored when restoring State 1 but the paging is set to page 1 as expected.

Kevin

desperado

@kthorngren Were you using my test case with ajax stateRestore enabled?

Here is a video of me running my test case.
https://watch.screencastify.com/v/MyhXQw5abaGO0fJmPLOH

http://live.datatables.net/pibehila/1/edit?js,output

Edit: I forgot to include demo of the Active State issue which is really just the same issue because page is being saved so switching the page make the state inactive.
So here is another video to demonstrate that related issue.

https://watch.screencastify.com/v/QjgfnOwpNm0sTekSJ1U8

kthorngren

Were you using my test case with ajax stateRestore enabled?

I used this test case:
http://live.datatables.net/pibehila/1/edit?js,output

I'll set something up to record my steps.

Kevin

kthorngren

Previously I was using the states that were created with my test case. I walked through the steps and created a new state and it does save the paging info. I added order: false and did some debugging:

The stateRestore object does have the page and order options even though there are set false in stateRestore.saveState.

Kevin

desperado

@kthorngren Thanks for confirming that there is an issue with stateRestore's disable page and order saving when using ajax to store state.

I wonder if the other disable option also don't work. I suspect that is likely. Good that you tested order as well to demonstrate that too is failing to honor the false setting.

@colin can you create an internal ticket to look into this?

colin

I've looked into this some more, and still not seeing it happening locally. I agree that the paging information is being stored, but for me, it's not being reloaded - so there's definitely a discrepancy between what I'm seeing in my test case and what you're seeing in yours. Definitely one for Sandy to look at next week when he's back in. I've raised it internally (DD-2493 for my reference) and we'll report back here when there's an update.

Cheers,

Colin

desperado

@colin Thanks for testing. Are you using ajax to load your States? I am finding the issue only happens if you load your data data via ajax and not use the default browser memory method.

colin

Yeah, I was, see my comment above from the 4th, so definitely one for Sandy to nose at, he'll be able to get his debugging tools involved and make sense of it.

Colin

desperado

@colin OK, I didn't understand you post on the 4th since you didn't provide a live datatables link. I thought you were just showing me the "correct" command to disable paging. No worries, I am find with waiting for sandy. Just wanted to followup on your comment by asking. Cheers and aloha.

sandy

Hi All,

Just to update you that I have been working on this this afternoon, but don't quite have it finished. I'll circle back next week and have a fix for you then.

All the best,
Sandy

desperado

@sandy Thanks for the update.

sandy

Hi All,

I've just pushed fixes for DD-2942 and DD-2943.

For DD-2493 I've created a new set of options for length. This can be set using the stateRestore.toggle.length and stateRestore.saveState.length properties.

You'll need the latest nightly builds for StateRestore and DataTables to get the changes working. Or, as always, you can wait for the next StateRestore and DataTables release which we hope will be in the next few weeks.

Thanks,
Sandy

colin

Just a note that I don't believe it's quite ready yet - the active state is still incorrect. We're taking a look and will report back once resolved,

Colin

desperado

@colin thanks for the update

desperado

@colin What is the status of this fix? Your last note said it was being reviewed because it wasn't quite ready yet.

Thanks,
Ron

colin

It looks like there were addressed last week, apologies for not getting back in touch. Could you try with the nightly releases here, please, and see if they work for you,

Colin