会话组 (Ctrl+G) 是否应该成为未保存的集合层?

#571 回顾中承诺过要对此进行跟进,因此这个问题被记录下来,而不是丢失在一个合并的线程中。 ** 现状 ** 在 #571 之后,编辑器有两个分组概念: | | 会话组 | 组合 | |---|---|---| | 持久化 | 否 — 内存中,在加载场景时清除 | 是 — packages/core/src/schema/collections.ts | | 由谁创建 | 按 Ctrl/Cmd+G 在多个选项中 | 项面板的"组合"部分 | | 点击成员 | 选择整个组 | 仅选择该节点 | | 生命周期 | 会话 | 项目 | | 撤销历史 | 不包含 | 包含 | 这两个都回答了"这些东西应该放在一起"。其中没有一个知道另一个。使用 Ctrl+G 将四张椅子分组的用户,并期望明天能找到这个组,将会感到失望,而使用集合的用户将无法从中获得点击选择所有功能。 ** 为什么 #571 将它们分开发布 ** 让 Ctrl+G 持久化意味着一个意外的按键按下会将一个未命名的"组 4"写入保存的项目,然后同步到协作者,并出现在每个人的撤销历史中。这比有两个概念的默认情况更糟糕。现在,这个理由已记录在 wiki/architecture/selection-groups.md 中,因此下一个人不必重新推导它。 ** 开放的问题: 是否应该让会话组成为集合的"未保存层",而不是一个平行概念? 具体来说,一个数据模型,具有"persisted: boolean"(或一个明确的提升步骤),其中 Ctrl+G 创建一个临时的,而"保存为集合"则将其提升。 赞成的理由: 为用户学习一个概念,为我们维护一个概念。 提升路径是一个自然的功能: 在工作时松散地分组,保留那些最终变成结构的组。 集合将获得点击选择所有功能,这是会话组添加的真正有用的行为。 反对的理由: 集合是一个"持久化、协作"的概念,具有撤销历史; 会话组则是故意没有。统一意味着临时层必须小心地排除持久化、同步和历史 — 共享模型有可能变成一个在每个使用场景中都有"if (persisted)"分支的联合,这比两个小而清晰的概念更复杂。 读取时的过滤是使会话组在删除+撤销后存活下来的原因(参见 selection-groups.md 中的"成员永远不会被清除"部分)。持久化的集合可能希望有真正的成员变化。 这些是相反的设计,并不明显地进行调和。 UI 入口位于不同的位置,并服务于不同的时刻。 ** 将解决这个问题: 用户是否真的希望 Ctrl+G 分组在重新加载后存活。 这是一个产品问题,而不是架构问题 — 如果答案是否定的,当前的分割是正确的,这个问题就关闭了。 在构建任何东西之前,值得观察"我的组被删除"报告。