Architecture: How to implement multi-element selection (V3-5) for cross-el...

Documentation for Sessions

🏗️ Architecture: How to implement multi-element selection (V3-5) for cross-el...

Date: 2026-03-24
Time: 15:18:23 UTC
Session: gspace1-263.8
Agent: angular
Confidence: 90%
Status: ✅ Documented


📋 Decision Context

Question:

How to implement multi-element selection (V3-5) for cross-element analysis and shared component extraction?

Task: Not specified


🎯 Decision Made

Chosen:

Shift+click in preview-bridge-client sends PVI_MULTI_SELECT message (vs normal STUDIO_ELEMENT_SELECTED). PviService maintains multiSelection signal array with toggle behavior. Toolbar repositions to centroid of all bounding rects. Rule engine runs per element with deduplication. Cross-element analysis detects shared ggs-* components and suggests extraction.

Options Considered:

  1. Drag-to-select rectangle (complex iframe coordinate mapping, fragile)
  2. Checkbox-based selection in sidebar (disconnected from visual preview)
  3. No multi-select in V3, defer to V4 (users already expect this from design tools)

💭 Reasoning

Multi-element selection enables a class of suggestions impossible with single selection: shared component extraction, consistent styling across related elements, bulk layout changes. Shift+click is the universal multi-select convention. Toggle behavior (Shift+click same element removes it) matches file explorer patterns. Centroid positioning keeps the toolbar centered among selected elements. The shared component detection compares childGgsComponents across selections using Set intersection — if 3 list components all use ggs-badge + ggs-button, suggesting extraction into a reusable row component is high value. This builds directly on V1's single-select foundation without breaking it.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation