Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undo/Redo system #3

Open
kettek opened this issue Nov 22, 2022 · 0 comments
Open

Undo/Redo system #3

kettek opened this issue Nov 22, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@kettek
Copy link
Owner

kettek commented Nov 22, 2022

There are two major approaches we can do in this regard.

  1. Specific "action" objects that can apply or unapply an operation.
  2. A generic diff-based undo/redo system.

In the case of the first, it is the most easily expandable and could actually contain diff undo/redo as the steps. In the case of the second, it would just be limited to major undo/redo diff.

In relation to this, how should we go about implementing undo/redo? Should there be one unified undo/redo system or should there be undo/redo within overlay scope (containing actions such as deleting/adding modules and adjusting base overlay properties) as well as within module scope (containing settings modification, box changes, etc.)? How should this tie in with the pubsub channels?

We could implement undo/redo in a distanced way from the actual objects they target. For example, with the following data structure:

  • overlays
    • overlay
      • <... settings, box ...>
      • modules
        • <... settings, box ...>

Changes to overlays would be submitted via unre.create('overlays', <overlay>), unre.destroy('overlays', overlayUUID), along with undo/redo methods. Per overlay would be similar: ur.update('overlay', <uuid>, <key>, <value>). Modules could work the same: ur.update('module', <uuid>, <key>, <value>).

Some more thought is required, especially in regards to how it'd interface with Svelte's reactive functionalities. Given that we already use reactive stores and similar, having a very loosely coupled undo/redo system should work just fine. The undo/redo system would only have to check if the overlay or module still exists, and if so, to modify, undo, or redo the appropriate reactive stores to the stored state.

One final note, it might be acceptable to just store the complete module/overlay state per undo/redo step, as the amount of actions the end-user will do will likely be limited in scope. The objects themselves likely never exceed a few kilobytes, so storing hundreds of undo/redo steps would only consume a few megabytes, which is negligible.

@kettek kettek self-assigned this Dec 25, 2023
@kettek kettek added the enhancement New feature or request label Dec 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant