🏗️ Architecture: Should generated platforms use NGXS for state management?

Date: 2026-03-12
Time: 03:11:47 UTC
Session: gspace1-206.6
Agent: storage
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

Should generated platforms use NGXS for state management?

Task: S206: Remove NGXS from generated platform template

🎯 Decision Made

Chosen:

Remove NGXS entirely from generated platforms. Use flash-persistence (autoFlashState) + Angular signals for ALL state management. Deleted 7 NGXS state files (AuthState, WidgetsState, ViewportState, PagesState, module-bridge, ngxs-state-persistence). CORE_STATES reduced to empty array.

Options Considered:

1. 1. Keep NGXS as dependency (adds 200KB+ bundle, requires @ngxs/store npm)
2. 2. Remove NGXS, use flash-persistence + signals (chosen)
3. 3. Migrate NGXS states to signal-based equivalents (too much work for template)

💭 Reasoning

NGXS was used in gspace1 for legacy state management (auth, widgets, pages, viewport). These states are already being migrated to flash-persistence + signals in gspace1 itself (CLAUDE.md: 'State: Signals (local) → RxJS (async) → NGXS (global only)'). Generated platforms are greenfield — no legacy to support. flash-persistence provides persistence + offline + sync natively, which NGXS doesn't. Removing NGXS eliminates a heavy dependency (@ngxs/store ^21.0.0 requires Angular >=21 but we're on 20), reduces bundle size, and aligns with the project's direction. The user explicitly stated: 'we should not use ngxs, we should stick to the usage of our flash-persistence and storage-system'.

📁 Files Involved

• libs/libs-foundational/core-angular/src/lib/state/state.providers.ts
• libs/libs-foundational/storage-system/src/angular/index.ts
• libs/core/module-base/src/lib/state/index.ts

🔗 Related

• Decision ID: dev_1773285104014_vd3w41s
• Session: 206
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation