Skip to content

Fix expression handling for literals vs. instance names#565

Open
AntoineGautier wants to merge 12 commits into
stagingfrom
ag/554-expr-literals
Open

Fix expression handling for literals vs. instance names#565
AntoineGautier wants to merge 12 commits into
stagingfrom
ag/554-expr-literals

Conversation

@AntoineGautier
Copy link
Copy Markdown
Collaborator

@AntoineGautier AntoineGautier commented May 19, 2026

Description

Fixes #554 and #564.

⚠️ Since the changes are significant, this PR targets the staging branch to allow reviewing the UI logic.
@JayHuLBL Please make sure staging is in sync with main before merging.

Dependencies

This includes #561, and should be merged after that PR.

Changes

Remove "none" operator wrapping

Bare literals (booleans, numbers, unambiguous values) were unnecessarily wrapped as {operator: "none", operands: [<value>]}. They are now stored directly:

- "value": {"operator": "none", "operands": [true]}
+ "value": true

This applies to both value fields and modifier expression fields. templates.json shrinks by ~373 KB (~14%).

Preserve Modelica string literal quoting

String literals from Modelica source (e.g. "\"foo\"" in modelica-json) are now stored with their surrounding double-quote characters in templates.json (e.g. "\"foo\""). This gives the client a reliable way to distinguish a literal string from an instance/variable name reference — previously indistinguishable.

Client interpreter updated

resolveToValue now handles the two string cases explicitly:

  • String with surrounding quotes → JSON.parse to recover the plain literal ("\"foo\"""foo")
  • Valid Modelica name → looked up in context as before

Server parser updated

getExpression / buildSimpleExpression no longer emit "none" wrapper expressions. String values from modelica-json are forwarded directly; the quoting from Modelica string literals is preserved as-is.

Testing

Unit tests have been included to validate the comparison with literal string assignment, where the literal string matches an instance name in the loaded context: cd client && npx jest -t "Comparison with literal string assignment"

End-to-end tests have also been performed by creating the SOO document with the following system options.

AHU

  • Separate dampers w/ dp
  • Modulating relief w/o fan
  • No heating coil
  • Freeze stat hardwired to both

Cooling-only box

  • 3 sensors = true

✅ The parameter dialogs are identical to the ones on main.
✅ The feature branch produces the same document as the main branch.

The fix has two parts:

1. **`transformIgnorePatterns`** — overrides the default "ignore all of
`node_modules`" rule, telling Jest it *should* transform uuid package.
2. **`babel-jest` transform + `babel.config.js`** — provides the actual
transformer for `.js` files, using `@babel/preset-env` targeting the
current Node version to convert ESM to CommonJS that Jest can consume.
Remove the `expandStringOperand` function and `evaluateExpression`
calls. Expressions are now kept in their raw form (strings or objects)
and only evaluated on the client side. This simplifies the server logic
and allows the client to handle type resolution in its own context.

Update type annotations to use `Expression | Literal` where applicable.
@AntoineGautier AntoineGautier marked this pull request as draft May 19, 2026 13:16
@AntoineGautier AntoineGautier changed the base branch from main to staging May 19, 2026 13:17
@AntoineGautier AntoineGautier marked this pull request as ready for review May 19, 2026 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix evaluateExpression for proper handling of literals VS instance names

2 participants