fix: constants silently dropped when pressing Enter in LD/FBD autocomplete

[thiagoralves]

Summary

• LD bug (data loss): Typing a constant (e.g. T#500ms, 5, 'hello') on a block input/output and pressing Enter showed an "Illegal variable name" toast and silently dropped the value — the input appeared accepted (yellow text) but compiled as 0
• FBD bug (cosmetic): Same scenario showed the error toast, but the constant was actually saved correctly since the blur handler wasn't suppressed
• Root cause: The autocomplete's Enter path unconditionally routed unmatched text to "Add variable" → createVariable(), which rejects literals via isLegalIdentifier(). In LD, blur({ submit: false }) then suppressed the blur handler that would have correctly processed the constant

Fix

Detect literals via getLiteralType() in two layers:

1. Autocomplete submit functions (LD + FBD): skip createVariable() for literals — prevents the error toast
2. LD Enter handlers (variable, contact, coil): pass submit: true for literals so the blur handler processes them with proper type validation

All IEC 61131-3 literal types are covered: numeric, time, date, TOD, datetime, string, and boolean constants.

Test plan

• Add a TON block in LD, type T#500ms on PT input, press Enter → no error toast, value accepted (yellow text), compiles correctly
• Same test but click outside instead of Enter → still works (regression check)
• Test other constant types: 5 on an INT input, 3.14 on a REAL input, TRUE on a BOOL contact
• Test typing a new variable name and pressing Enter → variable is created as before
• Repeat the T#500ms test in FBD editor → no error toast, value accepted
• Test selecting an existing variable from the autocomplete dropdown with Enter → still works

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Improved handling of literal type variables in autocomplete and input fields.
  • Fixed keyboard submit behavior for literal type values to prevent unintended variable creation.
  • Enhanced variable input validation for literal constants across graphical editor components.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between e414315 and debc1a9.

📒 Files selected for processing (5)

• src/renderer/components/_atoms/graphical-editor/fbd/autocomplete/index.tsx
• src/renderer/components/_atoms/graphical-editor/ladder/autocomplete/index.tsx
• src/renderer/components/_atoms/graphical-editor/ladder/coil.tsx
• src/renderer/components/_atoms/graphical-editor/ladder/contact.tsx
• src/renderer/components/_atoms/graphical-editor/ladder/variable.tsx

---

Walkthrough

The PR adds guards using getLiteralType() to prevent literal values from being incorrectly added as new variables. In autocomplete handlers, submissions skip when the search value is a literal. In blur handlers, submission is now conditional on whether the input value is a literal type.

Changes

Cohort / File(s)	Summary
Autocomplete Variable Submission Guards src/renderer/components/_atoms/graphical-editor/fbd/autocomplete/index.tsx, src/renderer/components/_atoms/graphical-editor/ladder/autocomplete/index.tsx	Added early-return guard using getLiteralType() in the add-variable path to prevent creating variables when the search value represents a literal type.
Blur Submission Conditional Logic src/renderer/components/_atoms/graphical-editor/ladder/coil.tsx, src/renderer/components/_atoms/graphical-editor/ladder/contact.tsx, src/renderer/components/_atoms/graphical-editor/ladder/variable.tsx	Modified blur invocation to conditionally set submit flag based on !!getLiteralType() of the current input value, enabling submission only for literal types.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Check invalid variable names #356 — Modifies variable submission logic with getLiteralType() checks to prevent literals from becoming variables in the same component files.
• LEC-220: Fix saving issue #230 — Modifies the autocomplete add-variable flow in the same FBD and ladder autocomplete files.
• fix: Resolve keyboard navigation for Add Variable in Ladder editor #533 — Addresses autocomplete/Enter-submit flow for variable addition with synchronous triggerSubmit handling.

Suggested labels

bug

Suggested reviewers

• JoaoGSP

Poem

🐰 A rabbit hops through literal fields,
Where types are guarded, no more yields,
Of phantom vars that shouldn't stay—
Blur and submit now know the way! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main bug being fixed: constants being silently dropped when pressing Enter in LD/FBD autocomplete.
Description check	✅ Passed	The description comprehensively covers the bug symptoms, root cause analysis, the fix approach with specific technical details, coverage of literal types, and a thorough test plan.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/ld-fbd-constant-literal-enter-key

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}