⚙️ Implementation: How should the expression engine handle repeated evaluations...

Date: 2026-03-25
Time: 21:47:55 UTC
Session: gspace1-270.6
Agent: storage
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

How should the expression engine handle repeated evaluations of the same expression?

Task: S270 Platform Elements Evolution

🎯 Decision Made

Chosen:

AST cache via Map<string, ASTNode> at module level. evaluateExpression() checks cache before tokenize+parse. Cache is bounded naturally by unique expressions per page (typically <50). No LRU or TTL needed.

Options Considered:

1. No caching (re-tokenize + re-parse every time)
2. Full result caching with context hash (complex, may stale)
3. AST-only caching (chosen — simple, correct, no invalidation needed)

💭 Reasoning

PE pages re-evaluate all pe-visible/pe-value/pe-disabled expressions on every field change. Without caching, each evaluation re-tokenizes and re-parses the same string. The AST is immutable — same expression always produces same tree. Only the evaluation context changes (field values). Caching the AST skips tokenize+parse entirely on re-evaluation. A page with 20 expressions evaluated on each keystroke saves 20 tokenize+parse calls per keystroke. Cache growth is bounded: a page has a finite set of unique expression strings. No cache invalidation needed since expressions don't change at runtime — they're HTML attributes.

📁 Files Involved

• libs/libs-structural/platform-elements/src/lib/runtime/expression/expression-evaluator.ts

🔗 Related

• Decision ID: dev_1774475275763_a8xic9n
• Session: 270
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation