Separate clear functions for undo-/redo-stacks

[pi3n4t]

Being able to clear both stacks individually would make it able to mimic the behaviour in most office-like apps, as the redo-stack gets cleared when making changes.

This would require the state to not get reset after clearing.

[andrewbeng89]

Hi @pi3n4t, thanks for your feedback on the plugin 👍

This sounds very much similar to an existing feature enhancement #13. Could you please have a look at this to clarify whether this is a duplicate?

[pi3n4t]

Thank you for your answer.

While yes, they are similiar in that this feature also would not reset the state, I think they are still different enough, as this feature would allow the clearing of both stacks individually at the devs discretion, instead of always both at the same time.

[pi3n4t]

Hello, I am currently developing this feature.

What are the requirements for an acceptable pull request?
I assume it's a functioning feature, some unit tests and a completed documentation.
Are there any other things that one should do, before submitting a pull request?

[andrewbeng89]

Hi @pi3n4t sorry for the delay in getting back.

Thanks for your time in developing and contributing to this project. 👍 I would say these would be some general guidelines:

• A list of expected features updated to this issue
• Corresponding unit tests
• Feature implementation passing against the tests
• Documentation would be very much appreciated, but not necessarily essential

[pi3n4t]

Thank you for the answer.
Here is my proposal for this issue:

Expected Features

• resetDone function which clears the done stack
• resetUndone function which clears the undone stack

These functions will not call the action RESET_STATE, but will update canUndoRedo.
They will also not get their own mutations, as the done and undone stacks will be updated by setConfig and the corresponding action/mutation.
This feature can then also be used by endusers to implement features like #53 in their own applications.

Feedback would be appreciated, as I am not too sure I understood all intentions in how the code was structured correctly.

[tobiascornille]

@pi3n4t Did you ever find a workaround?

[pi3n4t]

@tobiascornille I think so, yes. At some point I had something working, but didn't get the chance to test it enough to be sure that it's correct. Projects and scope changed. That is why I haven't submitted any code so far. But here is what I did anyway:

First I had to create the function resetUndone in this package, to clear the the undone stack without it clearing the state.
I mostly just copied the reset function but changed some things. The important part of the function looks like this:

async (namespace: string) => {
  const config = getConfig(paths)(namespace);

  if (Object.keys(config).length) {
    const undone: [] = [];

    setConfig(paths)(
      namespace,
      {
        ...config,
        undone
      },
      store
    );

    updateCanUndoRedo({ paths, store })(namespace);
  }
};

This function then also has to be exposed so you can call it from outside the module. IIRC you have to add some things in undoRedo.ts and list.ts, then build the module.

You could now call this action every time you call another action. I thought that's annoying though, so I wrote another vuex plugin that you can just add when intializing it. It looks something like this:

export default function emptyUndoneStack(store) {
  store.subscribeAction((action, state) => {
    if (
      state.undoRedoConfig.undone
      && state.undoRedoConfig.undone.length
      && action.type !== 'undo'
    ) {
      store.dispatch('resetUndone');
    }
  });
}

This function get's called for every action that you dispatch. In theory you could create a white-/blacklist to only clear the undone stack when certain actions are called.
I hope that helps at least a little until I get my butt up one day and finish testing my code to create a merge request with it.

[tobiascornille]

@pi3n4t Thank you for the write-up!