Blockly项目中ContextMenuItem API的scopeType属性废弃方案

背景介绍

Blockly作为一款流行的可视化编程工具，其上下文菜单系统允许开发者自定义各种操作选项。在当前的实现中，上下文菜单的显示范围受限于scopeType属性，这限制了菜单在非传统元素（如连接线等）上的应用灵活性。

当前限制与问题

现有API通过scopeType属性强制规定了上下文菜单只能出现在三种场景：

1. 代码块(blocks)
2. 工作区(workspaces)
3. 工作区注释(workspace comments)

这种硬编码的方式存在明显局限性，特别是当开发者希望在其他可聚焦元素（如连接线、自定义组件等）上显示上下文菜单时，现有机制无法满足需求。

技术方案设计

1. API变更

将ContextMenuItem类型中的scopeType属性标记为可选(optional)，为后续完全移除做准备。这一变更保持了向后兼容性，允许现有代码继续工作。

2. 兼容层实现

为确保平稳过渡，设计了一个兼容层处理逻辑：

• 注册时检测是否提供了scopeType
• 若有，则自动包装原有的preconditionFn
• 包装后的函数会在scope不匹配时返回'hidden'

这种设计使得现有代码无需立即修改就能继续工作，同时为迁移到新机制提供了缓冲期。

3. 条件判断迁移

将原有的基于scopeType的硬性范围检查，迁移到各个菜单项的preconditionFn中实现。例如：

• "删除块"菜单项应自行检查scope.focusedNode是否为Block类型
• 其他菜单项同理实现自己的可见性逻辑

4. 核心逻辑改造

移除contextmenu_registry.ts中getContextMenuOptions函数内基于scopeType的检查逻辑，完全依赖各个菜单项自身的preconditionFn来决定是否显示。

技术优势分析

1. 更强的灵活性：菜单项可以出现在任何可聚焦元素上，不再受限于三种固定类型
2. 更清晰的职责划分：每个菜单项自行决定显示条件，符合单一职责原则
3. 更好的可扩展性：新增菜单类型无需修改核心逻辑，只需实现自己的条件判断
4. 平滑过渡方案：兼容层设计确保现有代码不受影响

实施建议

对于Blockly开发者来说，这一变更意味着：

1. 新开发：应直接使用preconditionFn实现显示逻辑，不再依赖scopeType
2. 已有代码迁移：逐步将scopeType逻辑转移到preconditionFn中
3. 测试验证：确保自定义菜单项在各种场景下的显示行为符合预期

总结

这一API改造标志着Blockly上下文菜单系统向更灵活、更解耦的方向发展。通过将显示逻辑下放到各个菜单项自身，系统获得了更强的扩展能力，同时也为开发者提供了更精细的控制手段。兼容层设计确保了过渡期的平稳，体现了良好的API演进策略。