Are debounced undos supported?

[kadamwhite]

If we're updating a value in our store from a continuous input source, say, the X/Y position of an element that is being dragged, we'd like to only store an undo state when that action is complete. My instinct is that to do this we'd leverage the distinctState tool and filter on action types, updating the store when it's a drag operation and firing an action on mouseup that we'd use to persist the state; but since other actions may not have as clear a "terminator" as a mouseup, I wanted to learn whether there was any other potential solution to this problem. (Apologies if this is a mis-use of the issues thread)

[peteruithoven]

This isn't really what your asking for, but you might find it a interesting sollution anyway. We're "debounding" the successions of one action type based on time:

const IGNORE_TIME = 250;

let filter = true;
export default function undoFilter(action, currState, prevState) {
  // other filters 
  filter = rapidSameFilter(action);
  return filter;
}

// ignore rapid action types that are the same
let ignoreRapid = false;
let prevActionType;
function rapidSameFilter(action) {
  if (action.type !== prevActionType) {
    ignoreRapid = false;
    prevActionType = action.type;
    return true;
  }
  if (ignoreRapid) {
    return false;
  }
  ignoreRapid = true;
  setTimeout(() => {
    ignoreRapid = false;
  }, IGNORE_TIME);
  return true;
}

Inspiration: #24 (comment)

[pl12133]

@kadamwhite Thank you for sharing this issue, I think I am following you but I would like to make sure I'm understanding your use case. I'm wondering if you could tell me if this statement matches what you describe: "An action is dispatched repeatedly N times, only add the result of the last action to past."

@peteruithoven That is a very nice filter function, thank you for sharing! I think that covers the problem: "An action is dispatched repeatedly N times, only add one result to past per IGNORE_TIME milliseconds."

Trying to sum these problems up into a succinct sentence will help to document similar issues in the future. Ideally we can get a few common use cases together and put them all into an FAQ on filters.

[peteruithoven]

@pl12133 I'm hoping with #71 we can make it easier for people to combine filters and it will start making sense to share filters as packages.

[omnidan]

As debouncing gets asked a lot, I think it would make sense to add an example for this.

[kadamwhite]

@pl12133 :

I'm wondering if you could tell me if this statement matches what you describe: "An action is dispatched repeatedly N times, only add the result of the last action to past."

Correct, that's basically my question. Technically it would apply to several parameters; we have a drag-and-drop interface where x/y position and other attributes are calculated to control data visualization parameters in real time. We want those to update continuously, then have the final position at which the draggable ends up to be what gets snapshot.

I'll experiment with @peteruithoven's debouncer, that'll certainly get us closer towards what we want! Thank you all.

[peteruithoven]

I'm very curious how you will fix this. I can imagine a couple of solutions, but all seem to require more interface than what's currently available.

• Delete a history item (or just the previous one).
• Update / edit / override a history item (or just the previous one).
• Store an extra item in history in some kind of pre undo hook. Enabling you to when there is a different action type dispatched, store the last previous state.

[omnidan]

Closing this as it's been superseded by #88 - feel free to comment there, reopen or open a new issue if you feel it's necessary 😉