Architecture: How should page-builder relate to the Platform SDK and widge...
Documentation for Sessions
🏗️ Architecture: How should page-builder relate to the Platform SDK and widge...
Date: 2026-03-16
Time: 19:24:48 UTC
Session: gspace1-226.11
Agent: angular
Confidence: 91%
Status: ✅ Documented
📋 Decision Context
Question:
How should page-builder relate to the Platform SDK and widget system to avoid visual mismatch between editing and production?
Task: S226.2: Platform Generation v2 architecture design
🎯 Decision Made
Chosen:
Widget preview components (libs-widgets/widgets) must wrap SDK components (libs/core/ui-framework) instead of having their own inline rendering. Page-builder renders widgets → widgets wrap SDK components → same visual output as generated platforms.
Options Considered:
- Keep separate rendering in widgets and SDK (status quo — visual mismatch)
- Widget wrappers consume SDK components (chosen — single source of truth)
- Eliminate widget layer entirely and use SDK directly in page-builder (too disruptive)
💭 Reasoning
Currently, ButtonPreviewComponent has 399 LOC of inline CSS and rendering that is completely independent from GgsButton (57 LOC in ui-framework). This means what the user sees in page-builder is NOT what runs in the generated platform — different CSS, different variants, different sizes. The fix: ButtonPreviewComponent renders
📁 Files Involved
libs/libs-widgets/widgets/src/lib/button/components/button-preview.component.tslibs/core/ui-framework/src/lib/components/ggs-button/ggs-button.component.tslibs/libs-structural/page-builder/src/lib/components/canvas-widget/canvas-widget.component.tslibs/libs-structural/page-builder/src/lib/services/page-code-generator.service.ts
🔗 Related
- Decision ID:
dev_1773689088722_qyxb57e - Session: 226
- Workspace: gspace1
Auto-generated by MCP Smart Consolidation