LogicFlow 撤销操作导致自定义属性丢失问题分析与解决方案

问题现象

在使用 LogicFlow 进行 BPMN 流程设计时，开发人员发现当执行撤销操作后，节点中的所有自定义属性（properties）会被意外清空。具体表现为：用户修改了节点的多个属性后，点击撤销按钮，所有自定义属性值都恢复到了初始状态。

问题根源分析

经过深入排查，发现问题源于节点模型类的构造函数实现方式不当。具体原因如下：

1. 撤销操作机制：LogicFlow 的撤销/重做功能基于完整的 graphData 快照机制。当执行撤销操作时，会使用历史记录中的完整画布数据进行重绘。

2. 节点重建过程：在重绘过程中，所有节点都会被重新实例化，即会调用节点模型的构造函数。如果构造函数中对属性进行了重置操作，就会覆盖历史数据中的属性值。

3. 错误实现：原代码在构造函数中使用了 this.properties = { ...this.properties, ...defaultProperties } 这样的写法，导致每次实例化时都会用默认值覆盖已有属性。

解决方案

正确的实现方式应该是在调用父类构造函数前，先对传入的 data.properties 进行初始化判断：

class UserTaskModel extends RectNodeModel {
  constructor(data: LogicFlow.NodeConfig<UserTaskProperties>, graphModel: GraphModel) {
    // 先处理属性初始化
    data.properties ||= UserTaskPropertiesFactory.createDefault();
    // 再调用父类构造函数
    super(data, graphModel);
  }
}

这种实现方式有以下优点：

1. 仅在属性未定义时才设置默认值
2. 保留了撤销操作恢复的历史属性值
3. 符合 LogicFlow 的数据流设计

最佳实践建议

1. 属性初始化时机：对于自定义节点的属性初始化，建议在构造函数开始处处理，而不是在 super() 调用之后。

2. 响应式数据注意事项：当与 Vue 等响应式框架配合使用时，应注意将数据转换为普通对象后再传递给 LogicFlow 的 API，避免响应式代理影响撤销功能。

3. 属性合并策略：需要明确默认属性与自定义属性的合并策略，通常应该让用户设置的属性优先于默认值。

4. 调试技巧：可以通过监听 HISTORY_CHANGE 事件来观察撤销/重做时的数据变化，帮助定位问题。

总结

LogicFlow 作为一款专业的流程设计框架，其撤销/重做功能基于完整的数据快照机制。开发者在实现自定义节点时，需要特别注意构造函数中的属性处理逻辑，避免在实例化过程中意外覆盖历史数据。正确的属性初始化方式应该是在调用父类构造函数前，对传入的配置对象进行处理，这样可以确保撤销操作能够正确恢复所有自定义属性。