Promised as a follow-up in the #571 review, so the question is recorded rather than lost in a merged thread.
The situation. After #571, the editor has two grouping concepts:
|
Session groups |
Collections |
| Persisted |
No — in-memory, cleared on scene load |
Yes — packages/core/src/schema/collections.ts |
| Created by |
Ctrl/Cmd+G on a multi-selection |
The Collections section of the item panel |
| Click a member |
Selects the whole group |
Selects just that node |
| Lifetime |
The session |
The project |
| Undo history |
Not in it |
In it |
Both answer "these things belong together." Neither knows about the other. A user who groups four chairs with Ctrl+G and expects to find that grouping tomorrow will be disappointed, and a user who builds a collection won't get click-to-select-all from it.
Why #571 shipped them separate. Making Ctrl+G persist means a stray keypress writes an unnamed Group 4 into the saved project, which then syncs to collaborators and lands in everyone's undo history. That's a worse default than having two concepts. The reasoning is now in wiki/architecture/selection-groups.md so the next person doesn't have to re-derive it.
The open question: should session groups become the unsaved tier of collections rather than a parallel concept? Concretely — one data model, with a persisted: boolean (or an explicit promote step), where Ctrl+G creates an ephemeral one and "Save as collection" promotes it.
Arguments for:
- One concept for users to learn, one for us to maintain.
- The promote path is a natural affordance: group loosely while working, keep the ones that turn out to be structural.
- Collections would gain click-to-select-all, which is the genuinely useful behaviour session groups added.
Arguments against:
- Collections are a persisted, collaborative concept with an undo story; session groups are deliberately neither. Unifying means the ephemeral tier has to be carefully excluded from persistence, sync, and history — the shared model risks becoming a union with an
if (persisted) fork at every use site, which is more complexity than two small clear concepts.
- Read-time filtering is what makes session groups survive delete+undo (see the "Membership is never pruned" section in
selection-groups.md). Persisted collections presumably want real membership mutation instead. Those are opposite designs and the reconciliation isn't obvious.
- The UI entry points are in different places and serve different moments.
What would settle it: whether users actually want Ctrl+G groupings to survive a reload. That's a product question, not an architecture one — if the answer is no, the current split is correct and this issue closes. Worth watching for the "my groups disappeared" report before building anything.
Not blocking anything. Filing it so the overlap is a recorded decision with reasoning attached rather than an accident someone discovers later and "fixes" in the wrong direction.
Promised as a follow-up in the #571 review, so the question is recorded rather than lost in a merged thread.
The situation. After #571, the editor has two grouping concepts:
packages/core/src/schema/collections.tsBoth answer "these things belong together." Neither knows about the other. A user who groups four chairs with Ctrl+G and expects to find that grouping tomorrow will be disappointed, and a user who builds a collection won't get click-to-select-all from it.
Why #571 shipped them separate. Making Ctrl+G persist means a stray keypress writes an unnamed
Group 4into the saved project, which then syncs to collaborators and lands in everyone's undo history. That's a worse default than having two concepts. The reasoning is now inwiki/architecture/selection-groups.mdso the next person doesn't have to re-derive it.The open question: should session groups become the unsaved tier of collections rather than a parallel concept? Concretely — one data model, with a
persisted: boolean(or an explicit promote step), where Ctrl+G creates an ephemeral one and "Save as collection" promotes it.Arguments for:
Arguments against:
if (persisted)fork at every use site, which is more complexity than two small clear concepts.selection-groups.md). Persisted collections presumably want real membership mutation instead. Those are opposite designs and the reconciliation isn't obvious.What would settle it: whether users actually want Ctrl+G groupings to survive a reload. That's a product question, not an architecture one — if the answer is no, the current split is correct and this issue closes. Worth watching for the "my groups disappeared" report before building anything.
Not blocking anything. Filing it so the overlap is a recorded decision with reasoning attached rather than an accident someone discovers later and "fixes" in the wrong direction.