Architecture: How should Platform Elements handle business logic and compl...

Documentation for Sessions

🏗️ Architecture: How should Platform Elements handle business logic and compl...

Date: 2026-03-25
Time: 16:52:39 UTC
Session: gspace1-270.2
Agent: angular
Confidence: 90%
Status: ✅ Documented


📋 Decision Context

Question:

How should Platform Elements handle business logic and complex UI behavior beyond simple CRUD?

Task: Not specified


🎯 Decision Made

Chosen:

Hybrid architecture: (1) Constrained expression engine for client-side UI reactivity (pe-visible, pe-value, pe-disabled) — no full JS, just a safe formula DSL. (2) Declarative server actions (pe-action, pe-on-success) for mutations — 6-verb response vocabulary. (3) Angular Elements bridge library for the 5% of widgets too complex for Lit/vanilla (rich text editor, charts). Expression engine is 1.5KB, total bundle 37.9KB gzipped.

Options Considered:


💭 Reasoning

Researched Retool, Budibase, Appsmith, Salesforce Lightning, n8n, HTMX. The platforms with highest AI-authorability (HTMX, Budibase actions, Salesforce formulas) all use constrained vocabularies, not full JS. Full JS in declarations (Retool, Appsmith) creates quality cliffs for AI generation. The expression DSL is smaller than a SQL WHERE clause — Vitto already generates SQL-like patterns. Server actions keep business logic in NestJS where it belongs. Angular Elements bridge proves the hybrid gap can be closed for complex widgets without abandoning Platform Elements for everything.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation