How to we prevent StateRestore from adding state to the list if ajax call to save fails ?

desperado

I am working on code based on this example.
https://datatables.net/extensions/staterestore/examples/initialisation/ajaxFunction.html

At first my ajax call was failing with a authentication error but I noticed that the state still gets added to the list of states.
Of course on reload it's gone because nothing was saved.

But how to I report to the user that the save state failed and prevent the dropdown from adding the state?

It seems there should be a callback to stateRestore to inform it if the save state was successful or not.

sandy

Hi @desperado ,

You can defined your own ajax behaviour using the stateRestore.ajax initialisation option. You can make your own ajax call there using the data that the function provides. If you face an issue with saving then you can define your own behaviour in that function.

Thanks,
Sandy

desperado

@sandy I did apply my own function using stateRestore.ajax however when the ajax calls my server and there is some problem on the server side which causes the save to fail there seems to be no way to prevent StateRestore from adding the new state to the dropdown and marking it active as if the save was successful. This misleads the user into thinking the state is saved when it is not.

Here is an example. No server side implemented so I just simulate a failure each time.
https://jsfiddle.net/gouldner/d692a54m/

Also why does "save" action get sent for predefined states ? Are we not supposed to use predefined states with ajax ?

You will notice on run it calls save,save,load.

Now add a new state "State 1" and notice that it gets added to the list of states and marked active. How can I prevent that when the save fails ?

sandy

Hi @desperado ,

When you use the stateRestore.ajax initialisation option you are defining custom behaviour. That function is designed to be used to store the state over ajax - locally it is held in the js for operations. We have no way of knowing what people are going to instruct the stateRestore.ajax initialisation option to do, so you have to define the behaviour that handles failures. I'd suggest if there is a failure you make use of the stateRestore.state().remove() API method. It is much easier to do it this way than to force devs to read through all of the StateRestore code and understand how to correctly store a state using internal methods.

Yes you can use predefined states with ajax. A save occurs as when you define a state as predefined, you may not have saved it in other locations. To ensure consistency for the user it is expected that predefined states will be saved in the same way as normal states. That way if the table initialisation changes and the predefined sates are no longer present, they will still be available to the users who were using them before until they are deleted.

Thanks,
Sandy

desperado

@sandy Thanks I didn't think of making the remove call myself. What I expected was that I could return true/false from save to let the StateRestore know if it was successful or not. That's how a lot of other "widgets" I have used function.

I will implement the check for returned status and remove on failure as you suggested. It should be failing most of the time anyway, it was just failing because I am still figuring out the correct format and had some server permission issues at first. Of course failure is always an option

desperado

@sandy Just FYI doing what you suggested was quite tricky and in once case impossible. Not sure if there is a more elegant solution but it seems to me letting the call to the ajax function return true/false and then aborting the action on false could work. So when save is called if it returns true then add the state name to the dropdown otherwise do not. Likewise for delete and rename, if true take the action on the stateRestore object and dropdown update if false then abort the action on the stateRestore object and dropdown update. This might require a temporary object to hold the data to be sent to the functions but that seems possible as well. Anyway just some thoughts and feedback on this issue. I hope you don't find my persistence annoying, I am still very happy with this implementation but want to provide honest feedback on how my implementation is going.

To implement your solution I had to do the following

On save
When save fails
1. set a boolean blockStateRestoreRemove to true
2. call stateRestore.state(saveStateIdentifier).remove();
3. in remove code if blockStateRestoreRemove is true return without calling server
4. set boolean blockStateRestoreRemove back to false

When rename fails (if this isn't done you get infinite loop of rename failures)
1. set a boolean blockStateRestoreRename to true
2. call stateRestore.state(newStateIdentifier).rename(oldStateIdentifier)
3. in rename if blockStateRestoreRename is true return without calling server
4. set boolean blockStateRestoreRename = false

When remove fails (This one is impossible to fix)
The problem with this one is that the api stateRestore.state().save() doesn't take the state data as an optional argument it just saves the current state. So when the user tries to remove a state that is not currently active there is no way to restore the state that failed to be removed on the server side. Of course on the next page reload it will return but this issue make error handling inconstant in that the other two actions maintain the stateRestore in the same state as the server side even on failure, this one does not.

This is not a big deal but I wanted to point it out to you in case others start finding the same issue when trying to implement server side storage of states and you get more requests to implement some solution.

sandy

Hi @desperado ,

I think it still would be possible, but I agree it is not convenient for people. I've raised an issue internally (DD-2415 for my reference) and have pushed a fix.

The stateRestore.ajax function now takes a callback function as a second argument. When you have decided that your actions have been succesful, call that function and StateRestore will take it's actions on the client side.

This will be available in the next StateRestore release which we hope will be in the next few weeks. Until then you can access the fix from the nightly builds.

Thanks,
Sandy

desperado

@sandy The callback is working for rename and remove but not for save.
If I don't call the callback on save it still updates the dropdown with the new name and makes it active.

desperado

Here is an example you can test with to see that save takes it action even though I never call the callback.

http://live.datatables.net/kecomabu/1/edit

If you comment out the ajax and add some saved states you can see that rename and remove are not acting in the demo which is correct since I don't call the callback.

sandy

Hi @desperado ,

Thanks for pointing that out. I've reopened the issue and will report back when there is an update.

Thanks,
Sandy

sandy

Hi @desperado ,

That should be the issue fixed now. This will be available in the next StateRestore release which we hope will be in the next few weeks. Until then you can access the fix from the nightly builds.

Have a great christmas and a happy new year when it comes

Thanks,
Sandy

desperado

@Sandy My test case is still failing? I am using the nightly as you suggested but no change. When I click on "Create State" it calls my ajax function which does nothing and does NOT call the callback, but the new State is created and made active.

http://live.datatables.net/kecomabu/1/edit

desperado

@sandy Looking in github it looks like you fixed 6am today so I now suspect the problem is the "nightly" build has not yet occurred. I will test again tomorrow.

desperado

@sandy ITS WORKING NOW IGNORE LAST TWO COMMENTS