深度解析Web组态编辑器中的撤销重做架构设计

在开发Web组态编辑器时，许多功能看似简单实则复杂无比。其中，“撤销/重做”机制尤其具有挑战性，它影响用户体验和系统性能。本文旨在探讨为什么简单的快照方法难以满足生产级需求，并介绍一种更为稳健的设计思路。

一、为什么快照法在原型阶段表现良好

快照法的核心思想是将每次编辑操作后的状态保存为一份独立的快照，然后通过维护两个栈（undoStack 和 redoStack）来实现撤销和重做功能。这种方法简洁且易于理解：

interface EditorState {
  pages: Page[];
  activePageId: string;
  viewport: { x: number; y: number; scale: number };
  selection: string[];
}

const undoStack: EditorState[] = [];
const redoStack: EditorState[] = [];

function commit(state: EditorState) {
  undoStack.push(structuredClone(state));
  redoStack.length = 0;
}

function undo(current: EditorState): EditorState {
  if (undoStack.length <= 1) return current;
  const present = undoStack.pop()!;
  redoStack.push(structuredClone(present));
  return structuredClone(undoStack[undoStack.length - 1]);
}

这种方式在原型阶段表现良好，因为它易于实现和理解。然而，在实际生产环境中，这种设计很快就暴露出诸多问题。

二、为什么快照法会在生产环境中失效

历史记录粒度失控

用户的一次“拖动操作”可能触发数十个状态变化事件（如 pointermove），导致历史记录中充满无意义的中间状态。解决方法是将用户的意图建模为独立的操作，而不是每次事件的变化。

示例：

interface Command {
  label: string;
  do(): void;
  undo(): void;
}

class MoveNodeCommand implements Command {
  constructor(private id: string, private fromPos: { x: number; y: number }, private toPos: { x: number; y: number }) {}

  do() {
    moveNode(this.id, this.toPos);
  }

  undo() {
    moveNode(this.id, this.fromPos);
  }
}

内存和序列化成本过高

快照法需要频繁地深拷贝整个编辑状态，这不仅占用大量内存资源，还会导致性能下降。为了优化这一点，可以采用增量补丁（Patch）机制存储差异化的状态变化。

示例：

interface Patch {
  type: string;
  id: string;
  changes: { [key: string]: any };
}

function applyPatch(patch: Patch) {
  // 更新文档状态
}

不是所有状态都应被快照

编辑器的状态可以分为业务数据、UI临时状态和会话状态。只有业务数据需要纳入历史记录，而其他状态则不需要保存。

示例：

interface EditorState {
  document: DocumentSchema;
  ui: {
    hoverId?: string;
    guidelineVisible: boolean;
    contextMenuOpen: boolean;
  };
  session: {
    selection: string[];
    viewport: { x: number; y: number; scale: number };
  };
}

Redo的复杂性

用户撤销操作后进行新的编辑时，原有的重做分支需要被清理或合并。这种情况下，简单的栈机制无法处理复杂的分叉历史。

示例：

A -> B -> C -> D
          ↑ undo 到 B
B -> E -> F

无法应对副作用操作

许多编辑器中的动作不仅仅是数据更新，还涉及外部资源的同步和异步操作。快照方法难以处理这些复杂的逻辑。

示例：

class DeleteNodeCommand implements Command {
  constructor(private id: string) {}

  do() {
    deleteNode(this.id);
    // 同步删除关联连线
    deleteConnections(this.id);
  }

  undo() {
    restoreNode(this.id);
    // 恢复所有相关状态
    restoreConnections(this.id);
  }
}

三、一种更稳健的设计思路

操作建模与补丁机制

将用户的每个意图作为独立的操作进行建模，并使用增量补丁来描述状态变化，可以提高系统的性能和灵活性。

示例：

class MoveNodesCommand implements Command {
  label = '移动节点';

  constructor(
    private ids: string[],
    private before: Record<string, { x: number; y: number }>,
    private after: Record<string, { x: number; y: number }>
  ) {}

  do() {
    applyPositions(this.after);
  }

  undo() {
    applyPositions(this.before);
  }
}

历史管理

通过独立的历史管理模块来处理分叉、合并和裁剪等复杂操作，确保重做分支的正确性。

示例：

class HistoryManager {
  stack: Command[] = [];

  undo() {
    const command = this.stack.pop();
    if (command) {
      command.undo();
    }
  }

  redo() {
    const command = this.redoStack.shift();
    if (command) {
      command.do();
    }
  }

  push(command: Command) {
    // 处理分叉和合并
  }
}

状态分离与存储

将业务数据（文档状态）与UI临时状态分开管理，确保只有真正重要的状态进入历史记录。

示例：

interface EditorState {
  document: DocumentSchema;
  ui: UIState;
}

class UIState {
  hoverId?: string;
  guidelineVisible: boolean;
  contextMenuOpen: boolean;
}

通过这种方式，可以构建一个更高效和灵活的撤销/重做机制，从而提升Web组态编辑器的整体性能和用户体验。

使用Patch进行高效状态管理

为了提高撤销重做系统的效率和可维护性，建议采用基于Patch的状态更新方式，而不是每次操作都生成整个页面的快照。这种方式不仅存储量更小，还能让开发者更容易理解每一次操作具体修改了哪些内容。

使用Patch的好处包括但不限于：

• 减少冗余数据：仅保存实际变更的部分，避免全量状态的重复存储。
• 提升性能表现：在应用撤销或重做时，只处理必要的更改，加快响应速度。
• 增强调试能力：每条历史记录清晰地标明了变化细节，便于追踪和排查问题。

为此，可以设计如下数据结构来表示一次操作：

interface HistoryEntry {
  label: string;
  patches: Patch[];
  inversePatches: Patch[];
  timestamp: number;
  groupId?: string;
}

其中patches字段记录了正向变更信息（即将状态从旧版本变为新版本），而inversePatches则用于实现反向操作，即撤销时的逆运算。通过这种方式，可以在执行重做或撤销动作时高效地复原到任何历史状态。

完善的撤销管理器设计

为了构建一个既灵活又高效的撤销管理系统，可以参考下面的简化结构：

class HistoryManager {
  private undoStack: HistoryEntry[] = [];
  private redoStack: HistoryEntry[] = [];
  private maxSteps = 100;

  push(entry: HistoryEntry) {
    const last = this.undoStack[this.undoStack.length - 1];

    if (last && canMerge(last, entry)) {
      this.undoStack[this.undoStack.length - 1] = mergeEntry(last, entry);
    } else {
      this.undoStack.push(entry);
    }

    if (this.undoStack.length > this.maxSteps) {
      this.undoStack.shift();
    }

    this.redoStack.length = 0;
  }

  undo() {
    const entry = this.undoStack.pop();
    if (!entry) return;
    applyPatches(entry.inversePatches);
    this.redoStack.push(entry);
  }

  redo() {
    const entry = this.redoStack.pop();
    if (!entry) return;
    applyPatches(entry.patches);
    this.undoStack.push(entry);
  }
}

该结构的核心设计原则包括允许合并连续操作、限制历史栈长度以节省资源以及确保每次撤销或重做都能稳定执行。

典型问题及解决方案

在实际开发过程中，经常会遇到一些典型的问题。例如，鼠标移动事件被误认为是用户意图的历史记录导致拖拽动作生成过多的冗余快照；又如撤销操作时选中状态丢失造成用户体验不佳等问题。这些问题通常可以通过事务机制、选择合理的UI状态持久化策略和区分提交结果与临时交互效果来解决。

展望协同编辑模式

当考虑引入多人协作功能时，原有的单用户历史管理器将面临挑战。因此，在基础设计阶段就需要预留接口以支持复杂的协同工作流程，并能够有效地处理并发变更冲突等高级场景需求。

结论：撤销/重做是核心而非附加特征

尽管实现简单的撤销按钮看似简单直接，但为了确保系统的健壮性和扩展性，从长远来看应该将撤销/重做机制视为整个编辑器架构设计的重要组成部分。通过精心规划和逐步构建，可以打造出既简洁又强大的组态编辑工具。