CompilerEvolution

Compiler Evolution

This document describes the development path of the eQuantic.UI compiler, focusing on the transition from a simple syntactic transpiler to a robust, semantic-aware compilation engine.

🕰️ History

Phase 1: Syntax-Based Transpilation

Initially, the compiler operated through direct token-based substitutions.

• Limitation: It was difficult to handle method overloads or complex C# extensions.
• Result: TypeScript code that sometimes required manual adjustments.

Phase 2: The Strategy Pattern

We introduced the CSharpToJsConverter based on strategies (IConverterStrategy).

• Improvement: Each element of the syntax tree (AST) now has an isolated and testable conversion logic.
• Highlight: Implementation of native support for constructs like try-catch, switch and lambda expressions.

Phase 3: Semantic Awareness (Current)

Integration with the Roslyn Semantic Model allowed the compiler to understand the "meaning" of the code, not just its form.

• Context Heuristics: The compiler now knows how to differentiate when a variable is a Parameter (retains the name) or a Property (adds this.).
• Declarative Mapping: We replaced large switch blocks with a configurable mapping registry.

🚧 Safety Principles (Guardrails)

To ensure that the code executed in the browser is stable, the compiler imposes clear limits:

• Server/Client Split:
  • Server Components: Can use System.IO, DbContext, and database APIs.
  • Client Components: Restricted to UI logic, state, and portable APIs.
  • Enforcement: The compiler rejects the use of prohibited APIs (such as direct file access) in components that will be sent to the browser.

🔮 Future

The next major evolutionary leap will focus on the automatic Type-Safe Bridge, where the compiler will generate not only the ServerAction call but also ensure that return types and arguments are perfectly synchronized between C# and TypeScript at compile time.