🏗️ Architecture: How should Angular Element widgets persist per-user UI state...

Date: 2026-03-26
Time: 15:18:54 UTC
Session: gspace1-271.2
Agent: storage
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should Angular Element widgets persist per-user UI state (active board, view mode, hidden calendar groups) across page refreshes?

Task: Not specified

🎯 Decision Made

Chosen:

Use autoFlashState from @storage-system inside Angular Elements. Bootstrap Angular via createApplication() with provideFlashPersistence() providers. Flash state auto-persists to IndexedDB with cross-tab sync — same system the rest of the platform uses.

Options Considered:

1. Custom PeUserState with raw localStorage (simpler but violates flash-persistence convention)
2. autoFlashState from @storage-system (chosen — consistent with platform patterns)
3. Server-only persistence via user-preferences API (too slow for UI state)

💭 Reasoning

Initial attempt used custom PeUserState class with raw localStorage — this worked mechanically but violated the project convention of using flash-persistence for all state persistence (documented in docs/english/GoGrab-Space/theme-system/flash-persistence-integration.md). The fix: provide FlashStateHydratorService via provideFlashPersistence() in the createApplication() call that bootstraps Angular Elements. autoFlashState() then works normally inside component class field initializers (which run in Angular's injection context). Bundle size increase: 14.7KB → 25.7KB gzipped (acceptable for IndexedDB + cross-tab sync capabilities).

📁 Files Involved

• libs/libs-structural/platform-elements-angular/src/lib/register-all.ts
• libs/libs-structural/platform-elements-angular/src/lib/components/kanban-widget/kanban-widget.component.ts
• libs/libs-structural/platform-elements-angular/src/lib/components/calendar-widget/calendar-widget.component.ts

🔗 Related

• Decision ID: dev_1774538334384_5yk6xdy
• Session: 271
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation