最近做了一个 BI 平台的可视化看板编辑器,项目刚做完一期,各方面的功能都还能粗糙,但该有的也都有了,比如编辑器场景下最基本的两类时移操作-撤回(undo) 和恢复 (redo)。
用 vuex 实现的原理其实很简单,一句话就可以概括:维护一个 state快照 的历史记录数组和当前索引值, undo 和 redo 分别对应索引的回退(backward)的前移(forward)。
原理虽然简单,但代码实现还是要注意一些细节。
搭配源码@bugonly/vuex-undo-redo阅读口味更佳。
时间线不可逆
假设A为空白状态,依序进行以下操作:
- 新增一个组件1,进入状态B;
- 再次新增一个组件2,进入状态C;
- 执行undo操作,回退到状态B,组件2被清除,仅剩组件1;
- 新增一个组件3,进入状态D;
- 再次执行undo操作,回退到状态B,组件3被清除,仅剩一个组件1;
- 再次执行undo操作,组件1被清除,看板为空白状态,即状态A;
- 再次执行undo操作,提示无历史记录。
以上操作流程如下视频:
上述步骤中有争议的是步骤6,在测试过程中测试同事提出步骤6的表现应该是恢复到状态C,即组件2被恢复到看板中。如果是这样的话会发生以下问题:
- 状态B的 undo 操作结果会有两种:状态 A 和状态 C;
- 如何判断该什么时候回退到 A?什么时候回退到 C?
- 从状态B undo 回退到 C,再次 undo 应该回退到哪个状态?按时间线的话应该是回退到 B,那么再次 undo 呢?死循环?
之所以对步骤6的结果有争议,根本原因是混淆了编辑行为和时移行为。时移行为 undo/redo 恢复的是上一步/下一步的编辑行为,而时移行为本身是不被记录在操作历史栈中的,也就是说, undo 行为本身不能被 undo ,redo 行为本身不能被 redo。否则就会造成时间线混乱,难以管理。
时间线不可逆这条规则在所有类型的可视化编辑器中都是统一的,比如在线文档、IDE等等,大家有兴趣可以亲自去验证一下。
行为分类
并不是所有行为都是可以撤回的,理论上应该只有编辑行为可撤回,其他的比如页签之间的切换等简单交互的行为虽然也是状态机驱动(此处留个扣子,下文细聊),但并没有支持撤回的必要性,如果所有状态都能撤回反而令编辑器不好用。
所以在设计技术方案时,需要对用户行为进行归类,最基本要有三类:
- 支持撤回的行为;
- 不支持撤回的行为;
- 不支持撤回但是需要覆盖当前状态机快照的行为。
最后一种非常有必要,有些行为虽然本身不能撤回,但是在它之后的一些行为需要支持撤回,为了保持状态机的完整性,这类行为也必须记录下来,但是并不会作为一个独立的快照,而是覆盖当前快照。
举个例子。
- 页签1新增一个组件;
- 新增页签2;
- 页签2新增一个组件;
- 切换到页签1;
- 执行 undo,此时的表现是自动切换至页签2并且清除了页签2中的组件。
上述步骤中页签之间的切换行为就属于「不支持撤回但是需要覆盖当前状态机快照的行为」之一。在绝大多数交互场景中,页签之间的切换是没有必要使用 store 驱动的,往往是组件内部的状态机,上面示例之所以将它加入 store 就是为了实现视频中展示的 undo 自动切换页签效果。
这种方案比较简单有效,当然也有其他解决方案实现。
时移操作的作用域
这一点就很简单了,编辑器是应用的一个模块,在 vuex 中是 store 的一个 module,所以时移操作的插件函数在订阅 mutations 时需要判断 mutation-type,过滤非编辑器模块的 mutation。
const moduleFilterReg = new RegExp(`^${module}\/([a-zA-Z0-9\_]+)$`);
store.subscribe((mutation, state: Record<string, any>) => {
let mutationType = mutation.type;
if (moduleFilterReg){
const match = moduleFilterReg.exec(mutation.type);
// 过滤非指定模块的mutation
if (!match) {
return;
}
mutationType = match[1];
}
// ...其他逻辑
});
插件函数完整源码链接。
总结以上内容,时移操作插件的完整配置项如下:
interface IUndoRedoConfig {
/**
* 模块名称
* 如果指定模块则过滤此模块之外的所有 mutation
*/
module?: string;
/**
* 不跟踪的 mutation-type 清单
*/
noTraceMutationTypes?: string[];
/**
* 此列表中的 mutation-type 行为不跟踪,但是会覆盖当前历史记录
*/
needReplaceMutationTypes?: string[];
/**
* 过滤器,返回 false 时不执行后续逻辑
* 使用 filter 可以编写更复杂的过滤逻辑
* @param mutation
* @param state
*/
filter?: (mutation: MutationPayload, state:Record<string, any>) => boolean;
/**
* 历史记录容量,最小值1
*/
historyCapcity?: number;
}
页签域的时移操作如何实现?
最后留一个问题,这个问题我也暂时没想通最优解。目前市面上几乎所有的可视化编辑器都是这样的逻辑:时移操作的作用域的编辑器全局。
如何理解这句话呢?比如上文提到的报告编辑器,undo/redo 操作是针对报告 scope的,而不是页签 scope。报告编辑器可能有些人比较陌生,类比一种更普遍的编辑器:Excel。
Excel 的每个工作表(sheet)相当于报告中的页签,你试着在excel中执行以下步骤:
- 在 sheet 1 中任意编辑一次;
- 新建一个 sheet 2;
- 在 sheet 2 中任意编辑一次;
- 执行一次 undo,表现为 sheet 2中的编辑被还原;
- 再执行一次 undo,表现为 sheet 2 被整体清除;
- 再执行一次 undo,表现为 sheet 1中的编辑被还原。
以上步骤可以看出,excel 的 undo 行为是针对 excel 文档 scope 的,而不是每个 sheet 的 scope。
那么假如我想实现每个 sheet 域的时移操作呢?具体表现为:
- 每个 sheet 有单独的操作历史,互不影响;
- sheet 不能被时移操作删除,只能手动删除。
其实有很多种解决方案,最简单的就是每个 sheet 在 vuex store 对应一个 module,然后为每个 module 单独维护一个操作历史栈,这属于暴力解法,简单有效但很挫。也有更复杂的,比如基于图(Graph)数据结构做状态机发散,这属于自己牛逼同事看不懂的非工程解法,而且这个逻辑放在客户端会很重。所以这俩都不是最优解,更好的方案暂时不写了,因为我也没想出来...