You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two major approaches we can do in this regard.
Specific "action" objects that can apply or unapply an operation.
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.
The text was updated successfully, but these errors were encountered:
There are two major approaches we can do in this regard.
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:
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.
The text was updated successfully, but these errors were encountered: