🏗️ Architecture: How should the registerAngularElement bootstrap work to supp...

Date: 2026-03-26
Time: 15:29:35 UTC
Session: gspace1-271.7
Agent: storage
Confidence: 94%
Status: ✅ Documented

📋 Decision Context

Question:

How should the registerAngularElement bootstrap work to support all widget needs (DI, persistence, CDK)?

Task: Not specified

🎯 Decision Made

Chosen:

Single createApplication() call with shared providers array. provideFlashPersistence() for state persistence. All widgets share one Angular ApplicationRef (singleton injector). registerAngularElements() collects all providers BEFORE bootstrapping to avoid the provider-ordering trap where late providers are silently dropped.

Options Considered:

• No alternatives documented

💭 Reasoning

createApplication() bootstraps Angular once — subsequent calls to registerAngularElement() reuse the cached ApplicationRef. If providers are added after the first createApplication(), they never reach the injector. The fix: registerAngularElements() (batch version) merges all shared providers FIRST, then loops through elements calling registerAngularElement() which only creates the app on first call. provideFlashPersistence() must be in this initial provider set because autoFlashState() calls inject(FlashStateHydratorService) during component field initialization. CDK DragDrop works automatically because the CdkDropList/CdkDrag directives are in component imports[], not app-level providers.

📁 Files Involved

• libs/libs-structural/platform-elements-angular/src/lib/utils/register-angular-element.ts
• libs/libs-structural/platform-elements-angular/src/lib/register-all.ts

🔗 Related

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

Auto-generated by MCP Smart Consolidation