Users would often alternate between 2 values multiple times, through other means than history navigation.
Currently each alternation adds a history record, which is not very useful, since a record with the same value is only a handful of steps away.
It would be nice if the history had an algorithm to avoid this It would have to clean up a record with the same value if it's within X steps in history. X could be made configurable.
Do this on dispatch? Or filter when the history is used?
Possibly filtering history when needed is a better approach. The filtered result can be persisted (replace the unfiltered history array) if further usages of the history would filter it anyway.
That said, the current code doesn't add a history entry if the next action is dispatched before the debounce time ends (currently 500ms). If duplicate checking only runs when an entry is added, it wouldn't have much impact on performance anyway.
Users would often alternate between 2 values multiple times, through other means than history navigation.
Currently each alternation adds a history record, which is not very useful, since a record with the same value is only a handful of steps away.
It would be nice if the history had an algorithm to avoid this It would have to clean up a record with the same value if it's within X steps in history. X could be made configurable.
Do this on dispatch? Or filter when the history is used?
Possibly filtering history when needed is a better approach. The filtered result can be persisted (replace the unfiltered history array) if further usages of the history would filter it anyway.
That said, the current code doesn't add a history entry if the next action is dispatched before the debounce time ends (currently 500ms). If duplicate checking only runs when an entry is added, it wouldn't have much impact on performance anyway.