How to add a "Reset View" when using State Restore and Search Builder

How to add a "Reset View" when using State Restore and Search Builder

desperadodesperado Posts: 159Questions: 33Answers: 4

Before I added State Restore and Search Builder to my application I had implemented a "Reset View" in Buttons which did the following.

            {
                text: 'Reset View',
                action: function ( e, dt, node, config ) {
                    var table = $('#reviews-table').DataTable();
                    table.state.clear();
                    window.location.reload();
                }
            }

After implementing these extensions table.state.clear() no longer works.

Neither Search Builder nor State Restore provide a clear() method.

I need to have a "Reset View" in my application to return the DataTable to its initial state.
This needs to include returning the column visibility, sort column(s), Search Builder cleared and unset any selected view from resetView.

Currently I have State Restore configured with saving sort disabled because I don't like the fact that once a state is selected if you change your sorting it removes the "Active State" so the user no longer realizes they have other things changed. I am on the fence about this but I mention it because somehow saving the initial state into State Restore will not solve my issue as it will NOT restore the default sorting.

Answers

  • sandysandy Posts: 913Questions: 0Answers: 236

    Hi @desperado ,

    You created a GitHub issue relating to this where I supplied a solution suggesting that you create a default state that would reset the view.

    Currently I have State Restore configured with saving sort disabled because I don't like the fact that once a state is selected if you change your sorting it removes the "Active State" so the user no longer realizes they have other things changed. I am on the fence about this but I mention it because somehow saving the initial state into State Restore will not solve my issue as it will NOT restore the default sorting.

    It is possible to enable the saving of sorting when you create your initial state and then disable it once you have done that so that any new states that are created don't save the sorting.

    Thanks,
    Sandy

  • desperadodesperado Posts: 159Questions: 33Answers: 4

    @sandy Yes I know I created the git issue and you made the suggestion but I was having some difficult implementing the idea so rather then keep nagging you I decided to post here in hopes someone else had a good suggestion. I understand you solution to the sorting issue and I could probably do that.

    Another issue I had with your solution is as follows.
    If I create the "Reset View" state programmatically. I don't think I can prevent the user from deleting only that state. No state remove seems to be all or nothing. Predefined states always return because they are hard coded with their settings but your suggestion was to detect the page initial load and create the "Reset View" state when I see it doesn't exist.

    However, if the user removes the "Reset View" when another view is active or when the user has just changed things from the default state then the next time they visit the page I will see the missing "Reset View" and think it is the first time the user visited the page. So I will create the "Reset View" but with the wrong settings since I have saveState enabled.

    In addition if I elect to change the defaults based on user feedback people will already have the previous "Reset View" created and my application will not know to replace it. Not sure if there is some way that I could version it. But basically I will have to program a solution to this issue just because there is no way to return to the initial state when stateRestore is in use.

    At this point without table.state.clear() working I think my only option to let the user return to a given "Default" state is to create a pre-defined "Reset View" state. I didn't want to do this because of the bug I reported about pre-defined states no working with "Active" but now that you have fixed that I think I will just need to implement the predefined "Reset View" in each of my tables.

    I think if the user deletes "Reset View" state, then creates a new "Reset View" state when they load the page the predefined will win and replace the users change. Is that correct ? I tested and I think it is.

    Honestly, I still think it would just be so much simpler if stateRestore had a feature like table.state.clear();
    Is there a technical reason why this is not possible?
    If it is possible I think it will prevent future users from running into the same issue and having to ask about it.

    Sorry for long reply. I just needed to make the issues I am running into clear. Thanks so much for your efforts on this Extension. I am seriously delighted that this was implemented.

  • sandysandy Posts: 913Questions: 0Answers: 236

    Hi @desperado ,

    If I create the "Reset View" state programmatically. I don't think I can prevent the user from deleting only that state.

    You can create your own stateRestore button and disable removing it. See this example. Is this closer to what you want to do? Then you can set whatever config you like within the button config - basically a predefined state but not actually within the StateRestore collection.

    I think if the user deletes "Reset View" state, then creates a new "Reset View" state when they load the page the predefined will win and replace the users change. Is that correct ? I tested and I think it is.

    Yes that is the case - predefined states will always be shown if they are defined in the initialisation.

    Is there a technical reason why this is not possible?

    It would be possible to do but would involve some guess work. For example if you have stateSave enabled should the table reset to that's initial state, or the initial state based off of your initialisation? At the moment we think that because it is possible to implement a reset state in a number of different ways already there is no reason to spend dev time implementing another. It makes sense to use what has already been implemented where possible.

    If enough others also show interest in this in the future then we may implement it. Otherwise you are welcome to implement it yourself and create a pull request on GitHub :)

    Hope this helps,
    Sandy

Sign In or Register to comment.