BlockNote项目中临时性内容块与撤销历史的优化实践

在基于BlockNote构建的富文本编辑器中，开发者常常需要实现一些临时性的UI辅助元素或决策引导块。这类内容块通常作为用户交互的中间态存在，完成使命后便不再需要保留。然而，当用户触发撤销操作时，这些已被移除的临时块会重新出现，这显然不符合设计预期。

核心问题分析

传统编辑器中的撤销历史机制会记录所有内容变更操作。对于临时性内容块而言，它们被插入后又立即被移除的场景会产生两条历史记录：

1. 插入临时块的操作
2. 移除临时块的操作

当用户执行撤销时，编辑器会先回退到"移除临时块"前的状态，导致已被清除的临时块重新出现。这种现象破坏了用户体验的一致性。

技术解决方案

BlockNote的Transaction系统提供了细粒度的历史记录控制能力。通过设置事务元数据，开发者可以精确控制哪些操作需要进入撤销历史栈：

editor.transact(tr => {
  // 插入临时内容块
  editor.insertBlocks({...});
  
  // 关键配置：禁止本次事务进入历史记录
  tr.setMeta("addToHistory", false);
});

实现原理

该解决方案的核心在于：

1. transact方法创建了一个原子性的事务操作
2. setMeta设置了事务的元数据标记
3. 当addToHistory设为false时，整个事务（包括其中的所有操作）都不会被记录到撤销历史中

这种机制相比完全清空历史栈或选择性删除历史记录更为优雅，它从源头避免了无效历史记录的生成。

最佳实践建议

1. 明确临时块的生命周期：在插入前就确定该内容是否需要排除在历史记录外
2. 事务封装：将相关操作封装在单个事务中保证原子性
3. 异常处理：考虑在事务失败时的回滚逻辑
4. 性能考量：频繁创建临时块时需注意内存管理

扩展思考

这种模式实际上提供了一种通用的"临时状态"管理方案，不仅适用于内容块，也可以用于：

• 临时的样式修改
• 交互过程中的中间状态
• 自动完成组件的临时展现

理解这种机制有助于开发者构建更符合用户心智模型的编辑器交互行为，使撤销/重做功能真正服务于用户的意图而非机械地回放操作记录。