🏗️ Architecture: How should built-in property templates coexist with backend ...

Date: 2026-03-24
Time: 17:37:57 UTC
Session: gspace1-131.7
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should built-in property templates coexist with backend API templates?

Task: Page builder production readiness — template merge strategy

🎯 Decision Made

Chosen:

Merge strategy where built-in TypeScript/JSON templates take precedence over backend MongoDB templates when both define the same template ID

Options Considered:

1. Backend templates always override built-in
2. Built-in templates always override backend
3. Merge with built-in taking precedence
4. Version-based merge (newest wins)
5. Separate namespaces for backend vs built-in

💭 Reasoning

Root cause: The UnifiedPropertyService.loadAll() previously replaced all templates with backend API response, discarding built-in templates. Backend MongoDB had stale templates (e.g., typography with CSS variable values like var(--text-xs) instead of human-readable 12px). The built-in TypeScript templates had correct pixel values. Solution: loadAll() now (1) loads backend templates into a Map, (2) loads built-in templates into the same Map (overriding duplicates), (3) returns merged array. This means built-in templates always win for same-ID collisions, while backend-only templates are still available. Added getBuiltinTemplates() that combines TypeScript templates + JSON templates. This pattern ensures the frontend has correct defaults even if the backend database is stale.

📁 Files Involved

• libs/libs-foundational/core-properties/src/lib/unified/unified-property.service.ts

🔗 Related

• Decision ID: dev_1774373877484_n38fcz7
• Session: 131
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation