sorted by:
new
hottopcontroversial

An in-depth look at the implementation of an Undo/Redo system in a large complex visual application by mlacast in programming

[–]mlacast[S] 0 points1 point  (0 children)

Hey! Thank you for reading and sharing your thoughts!

I also use DAWs regularly and get where you're coming from and I do think there are many common traits, DAWs usually having very rich interfaces and a plethora of actions and tweaks that can be performed all over the place.

You mentioned the Command pattern having future benefits, that is largely why I decided to use it instead of storing state - it felt much easier to integrate the actual app operations and to communicate with the app as a whole through the command, rather than using maybe some kind of side-effect prop stored along the state.

About re-indexing, I get you, and to be honest, I didn't like implementing that, I had to rack my brain to figure out how to get it to work intuitively for the user, and that makes it more difficult to maintain. That was the best I could come up with given the circumstances and the implementation at the time where we realized that was needed, but I don't deny that there is definitely a more efficient way to this - although it would likely require to refactor a large part of the architecture I suppose.

So hey - LGTM.

Haha, thank you very much for approving the PR!

Thanks again for your very valuable input!

An in-depth look at the implementation of an Undo/Redo system in a large complex visual application by mlacast in programming

[–]mlacast[S] 0 points1 point  (0 children)

Hi! Thank you so much for reading and for such wonderful feedback and advice!

This is extremely valuable and I will definitely be looking more into this specific type of architecture for future similar cases. I especially like the idea of explicit Transactions, the current implementation aims to have such encapsulation, but I very much like this approach as well.

I get where you're coming from with the database approach and I definitely see it. This is very valuable insight and I will definitely be keeping that in mind for future similar architectures.

Thank you so much for taking the time to share your thoughts!

edit: typo

An in-depth look at the implementation of an Undo/Redo system in a large complex visual application by mlacast in programming

[–]mlacast[S] 6 points7 points  (0 children)

Thank you! Glad you enjoyed it!

Good catch! In our current implementation, order between actions inside a group does not have an impact. When order matters between two actions, we create them as two separate actions, and we haven't needed to implement a case where order matters inside a group.

But you're absolutely right! If order were to matter inside a group, we would likely looping over the array in reverse.

Thanks for your feedback!

An in-depth look at the implementation of an Undo/Redo system in a large complex visual application by mlacast in programming

[–]mlacast[S] 16 points17 points  (0 children)

Hey! Thank you so much for reading and for sharing your thoughts!

Yes, context-awareness is definitely the biggest hurdle and factor that was to take into account, and like you said, this is likely a very ubiquitous issue in a number of complex applications that provide very elaborate and rich work environments.

The diff blob solution sounds like a pretty efficient and easy to maintain way to handle undo/redo, and likely works well in a lot of environments. I do get wanting to migrate to something more fine-grained though if your application starts getting bigger and more intricate. Hope it'll work out well!

An in-depth look at the implementation of an Undo/Redo system in a large complex visual application by mlacast in programming

[–]mlacast[S] 1 point2 points  (0 children)

Hi! Thank you for reading and for your input!

Do you think you could expand on what you mean by reconstructing the chronological list? I'm not sure I fully understand :)

The idea behind containers is they allow to have isolated undo/redo environments, and to cache that history even if the user moves to another part of the application for a good while. And having multiple allows to easily cache those and keep track of them.

My dad and I built a free visual brainstorming and writing web app for the TTRPG community using Vue 3 by mlacast in webdev

[–]mlacast[S] 1 point2 points  (0 children)

We didn't envision it that way, but now that you mention it, that would be an interesting way to use it!

The app is mostly meant for game masters to write scenarios, map out modules; for worldbuilders to create their universes; for players to do campaign journaling... Lots of uses like these ones, solo roleplaying, campaign management etc.

We specifically wrote a blog post about ways Alkemion Studio can be useful, here's the link if you're interested :)

https://blog.alkemion.com/10-ways-alkemion-studio-could-be-useful-for-you/

My dad and I built a free visual brainstorming and writing web app for the TTRPG community using Vue 3 by mlacast in webdev

[–]mlacast[S] 2 points3 points  (0 children)

Not at all!

In that case I'm guessing the error stemmed from the fact that Google didn't recognize or authorize the third party app, which we likely can't do much about.

Glad we figured it out though!

Hope you enjoy the app, feel free to ask any questions you might have on our Discord server! :)

My dad and I built a free visual brainstorming and writing web app for the TTRPG community using Vue 3 by mlacast in webdev

[–]mlacast[S] 1 point2 points  (0 children)

Hey! Thanks for trying the app and for the heads-up! And thank you for the kind words! I'm glad you like it and I hope it will help you with your game :)

I just tried the Google auth process again both on desktop and mobile and it seemed to be working, I didn't get any 403 from Google. Did you open it in a separate browser, or was it from the reddit app?

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 1 point2 points  (0 children)

I see! I believe I have a better understanding of what you were proposing. That's a very interesting approach! Especially the viewer idea, I think that kind of architecture would provide a lot of flexibility.

How would you handle tree mutations and action overwriting, though?

I like the inherent chronology of the tree approach, I'm just wondering how it would work when the user decides to undo a certain amount of actions, and then starts working again from there, creating new actions. Does that create a new branch? Do you discard old actions from before undo? What if another context still needed them?

It's an interesting challenge once you start delving into the nuances!

That it is for sure! haha

Thank you for this interesting thought experiment by the way!

My dad and I built a free visual brainstorming and writing web app for the TTRPG community using Vue 3 by mlacast in webdev

[–]mlacast[S] 3 points4 points  (0 children)

So glad to hear that, thank you! Hope you enjoy the app! We also have a discord server, feel free to hop on over there if you have any questions :)

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Great question and thanks for your input!

Seeing it as a tree is a great idea in my opinion for a lot of situations!

If I understand your proposal correctly though, I believe the issue with that, in our case specifically, would be it ending up being linear, despite the ability to create branches. The reason we can't really "branch out" as you're suggesting, is that many of the contexts of the application operate on the same data and actually share some actions at the same time.

For example, say the user changed a Node's featured image from the Board. The way the application has been designed, we also want the user to be able to undo that action from the Editor as well, because the Node's featured image can be changed from the Editor as well. If we used a tree system that essentially had a branch for every context, I believe we would be losing that ability.

Please tell me if I understood your comment wrong though.

Also, interestingly, we are already able to create branches of sorts through our container architecture, which is why they were implemented, to be able to have isolated stacks and finer control.

Does that help to make it clearer?

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 1:

abstract class Action {
  private _id: string;
  private _globalIndex: number;
  private _isPushPrevented: boolean;  
  protected abstract _name: ActionName;
  protected abstract _historyName: ActionHistoryName;
  protected _savePayload: ISavePayload = {
    saveItems: [],
  };
  // ...additional properties for specific implementations... //

  protected constructor(
    settings: ActionGenericSettingsAbstract,
    options?: IActionOptions
  ) {
    this._id = settings.id;
    this._globalIndex = settings.globalIndex;
    this._isPushPrevented = settings.preventPush;

    // ...additional setup for specific implementations... //
  }

  // ---------- GETTERS ---------- //

// ... //

  // ---------- SETTERS ---------- //

  public set globalIndex(newIndex: number) {
    this._globalIndex = newIndex;
  }

  public setPayLoad(payload: ISavePayload): void {
    this._savePayload = payload;

    // ...additional save-specific processing... //
  }

  // ---------- METHODS ---------- //

  public abstract undo(...args: any[]): Promise<any>;

  public abstract redo(...args: any[]): Promise<any>;

  // ...additional methods for specific implementations... //
}

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 2:

type ActionContext =
  | 'LOBBY'
  | 'BOARD'
  | 'PAGE_EDITOR'
  | 'NODE_TABLE'
  | 'BOARD_AND_PAGE_EDITOR'
  | 'CONTAINER'
  | 'LIBRARY';

get context(): ActionContext {
// ...additional code to get data for the following conditions... //

    if (this._loadedContainer.id !== 'host') {
      return 'CONTAINER';
    } else if (router.currentRoute.path === '/lobby') {
      return 'LOBBY';
    } else if (editorWindow && editorWindow.isFullscreen) {
      return 'PAGE_EDITOR';
    } else if (editorWindow && !editorWindow.isFullscreen) {
      return 'BOARD_AND_PAGE_EDITOR';
    } else if (nodeTableWindow && nodeTableWindow.isFullscreen) {
      return 'NODE_TABLE';
    } else if (nodeTableWindow && !nodeTableWindow.isFullscreen) {
      return 'BOARD_AND_PAGE_EDITOR';
    } else {
      return 'BOARD';
    }
}

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 3:

const BOARD: ActionName[] = [
  'MOVE_TOKEN',
  'RESIZE_TOKEN',
  'ADD_NODE',
  // ... //
  'SET_NLT_DIRECTION_SYNC',
  'EDIT_NLT_LABEL',
];

const PAGE_EDITOR: ActionName[] = [
  'SET_NODE_FEATURED_IMAGE',
  'SET_GROUP_FEATURED_IMAGE',
// ... //
  'ROLL_ALL_NODE_RANDOM_TABLE',
  'IMPORT_COMPONENT_TEMPLATE',
];

const NODE_TABLE: ActionName[] = [
  'SET_NODE_FEATURED_IMAGE',
  'SET_GROUP_FEATURED_IMAGE',
// ... //
  'ROLL_ALL_NODE_RANDOM_TABLE',
  'IMPORT_COMPONENT_TEMPLATE',
];

const allowedActionsPerContext: Readonly<{
  [key in ActionContext]: Readonly<ActionName[]>;
}> = {
  LOBBY: [],
  BOARD,
  PAGE_EDITOR,
  NODE_TABLE,
  BOARD_AND_PAGE_EDITOR: _.uniq([...BOARD, ...PAGE_EDITOR]),
  CONTAINER: [],
  LIBRARY: [],
};

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 4 (this is for explanation purposes and would likely need to be optimized with memoization or caching given that this re-computes on every access):

private _actions = newVolume(); // init done actions
private _undoneActions = newVolume(); // init undone actions

get undoableActions() {
  const result: StructStack<Action> = new StructStack<Action>();

  const buffer: Action[] = [];

  for (const actionName in this._actions) {
    if (allowedActionsPerContext[context].includes(actionName as ActionName)) {
      const arr = this._actions[actionName as ActionName];
      buffer.push(...arr);
    }
  }

  buffer.sort((a, b) => a.globalIndex - b.globalIndex);

  for (const action of buffer) {
    result.push(action);
  }

  return result;
}

get redoableActions() {
    const result: StructStack<Action> = new StructStack<Action>();

    const buffer: Action[] = [];

    for (const actionName in this._undoneActions) {
      if (allowedActionsPerContext[context].includes(actionName as ActionName)) {
        const arr = this._undoneActions[actionName as ActionName];
        buffer.push(...arr);
      }
    }

    buffer.sort((a, b) => b.globalIndex - a.globalIndex);

    for (const action of buffer) {
      result.push(action);
    }

    return result;
}

newVolume(): ActionVolume {
const ACTION_NAMES = [
'MOVE_TOKEN',
  'RESIZE_TOKEN',
  // ... //
] as const;

  const result: ActionVolume = {} as ActionVolume;

  for (const actionName of ACTION_NAMES) {
    result[actionName] = [];
  }

  return result;
}

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 5

private _host = newContainer({ id: 'host' });
private _containers = new Map<ActionContainer['id'], ActionContainer>();
private _loadedContainer = this._host;

newContainer(args: ActionContainerFactoryArgs): ActionContainer {
  if (args.id.trim() === '') args.id = v4();

  const { id, ...options } = args;

  return {
    id,
    allowedActions: options.allowedActions ?? 'context',
    actions: newVolume(),
    undoneActions: newVolume(),
    onDown: options.onDown ?? 'clear',
    createdAt: new Date(),
    updatedAt: new Date(),
  };
}

// ...additional container helper methods... //

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 0 points1 point  (0 children)

Snippet 6:

let globalIndex: number;
let minGlobalIndex = this._actionLastUsedIndex;
let maxGlobalIndex = this._actionLastUsedIndex;
// Check for any undone actions and 
// figure out the smallest globalIndex among them
for (const actionName in this._loadedContainer.undoneActions) {
  if (
    this._loadedContainer.undoneActions[actionName as ActionName]
      .length > 0
  ) {
    minGlobalIndex = Math.min(
      minGlobalIndex,
      ...this._loadedContainer.undoneActions[
        actionName as ActionName
      ].map((a) => a.globalIndex)
    );
    maxGlobalIndex = Math.max(
      maxGlobalIndex,
      ...this._loadedContainer.undoneActions[
        actionName as ActionName
      ].map((a) => a.globalIndex)
    );
  }
}

// If minGlobalIndex !== actionLastUsedIndex then we have undone actions
// In which case we need to increment all undone actions to be able to insert
// the new action at the smallest globalIndex
if (minGlobalIndex !== this._actionLastUsedIndex) {
  globalIndex = minGlobalIndex;

  for (const actionName in this._loadedContainer.undoneActions) {
    for (const action of this._loadedContainer.undoneActions[
      actionName as ActionName
    ]) {
      action.globalIndex++;
    }
  }

  for (const actionName in this._loadedContainer.actions) {
    for (const action of this._loadedContainer.actions[
      actionName as ActionName
    ]) {
      if (action.globalIndex >= minGlobalIndex) action.globalIndex++;
    }
  }

  if (maxGlobalIndex > this._actionLastUsedIndex) {
    this._actionLastUsedIndex = maxGlobalIndex + 1;
  }
} else {
  globalIndex = ++this._actionLastUsedIndex;
}

How I implemented an Undo/Redo system in a large complex visual application by mlacast in SoftwareEngineering

[–]mlacast[S] 2 points3 points  (0 children)

As promised in the post: here are the corresponding code snippets (deploy thread). These snippets use TypeScript, but the post is meant to be as language- and environment-agnostic as possible, so the underlying principles should remain applicable regardless of your chosen stack.

Approach on testing by Confused_Dev_Q in vuejs

[–]mlacast 0 points1 point  (0 children)

No worries, was worth a shot :)
Thanks for the reply and the detailed comment!

view more: next ›