Fix reroute links not snapping correctly

[benceruleanlu]

Summary

• Route LGraphNode slot position queries through a single source of truth that prefers layoutStore’s DOM‑tracked slot positions and falls back to geometry when unavailable.
• Ensures that reroute‑origin drags snap to the same visual slot centers used by Vue nodes when hovering compatible nodes.

What changed

• LGraphNode.getInputPos/getOutputPos now resolve via getSlotPosition(), which:
  • Returns the Vue nodes layoutStore position if the slot has been tracked.
  • Otherwise, computes from node geometry (unchanged fallback behavior).
• LGraphNode.getInputSlotPos(input) resolves index→getSlotPosition() and retains a safe fallback when an input slot object doesn’t map to an index.

Why

• Previously, when starting a drag from a reroute and hovering a node, the temporary link endpoint would render toward LiteGraph’s calculated slot position, not the Vue‑tracked slot position, causing a visible mismatch.
• By making all slot position lookups consult the layout store first, node hover snap rendering is consistent across slot‑origin and reroute‑origin drags.

Impact

• No behavior change for non‑Vue nodes mode or when no tracked layout exists — the legacy calculated positions are still used.
• Centralizes slot positioning in one place, reducing special‑case logic and making hover/drag rendering more predictable.

#5780 (snapping) <-- #5898 (drop on canvas + linkconnectoradapter refactor) <-- #5903 (fix reroute snapping)

┆Issue is synchronized with this Notion page by Unito

[github-actions]

🎭 Playwright Test Results

⚠️ Tests passed with flaky tests

⏰ Completed at: 10/03/2025, 02:00:41 PM UTC

📈 Summary

• Total Tests: 492
• Passed: 460 ✅
• Failed: 0
• Flaky: 2 ⚠️
• Skipped: 30 ⏭️

📊 Test Reports by Browser

• ✅ chromium: View Report • ✅ 451 / ❌ 0 / ⚠️ 2 / ⏭️ 30
• ✅ chromium-2x: View Report • ✅ 2 / ❌ 0 / ⚠️ 0 / ⏭️ 0
• ✅ chromium-0.5x: View Report • ✅ 1 / ❌ 0 / ⚠️ 0 / ⏭️ 0
• ✅ mobile-chrome: View Report • ✅ 6 / ❌ 0 / ⚠️ 0 / ⏭️ 0

---

🎉 Click on the links above to view detailed test results for each browser configuration.

[claude]

Comprehensive PR Review

This review is generated by Claude. It may not always be accurate, as with human reviewers. If you believe that any of the comments are invalid or incorrect, please state why for each. For others, please implement the changes in one way or another.

Review Summary

PR: Fix reroute links not snapping correctly (#5903)
Impact: 27 additions, 8 deletions across 2 files
Files Modified:

• src/lib/litegraph/src/LGraphCanvas.ts
• src/lib/litegraph/src/LGraphNode.ts

Issue Distribution

• Critical: 0
• High: 0
• Medium: 0
• Low: 0

Category Breakdown

• Architecture: 0 issues
• Security: 0 issues
• Performance: 0 issues
• Code Quality: 0 issues

Key Findings

Architecture & Design

✅ Excellent architectural consistency: The PR correctly centralizes slot position calculations through the existing getSlotPosition function, which follows the established pattern of consulting the layout store first before falling back to geometry calculations.

✅ Proper abstraction layer: The changes maintain clean separation between Vue node layout (DOM-tracked) and LiteGraph geometry calculations, with appropriate fallback behavior.

✅ Consistent implementation: All six modification points follow the same conditional pattern: LiteGraph.vueNodesMode ? getSlotPosition(...) : legacyMethod(...)

Security Considerations

✅ No security implications: The changes are purely computational and don't introduce any security vectors. All inputs are properly typed and validated through existing mechanisms.

Performance Impact

✅ Performance neutral: The changes add minimal conditional checks (LiteGraph.vueNodesMode) but don't introduce expensive operations. The getSlotPosition function itself is already optimized with layoutStore caching.

✅ Bundle impact: No additional dependencies or imports, changes only routing of existing function calls.

Integration Points

✅ Backward compatibility maintained: Non-Vue nodes mode continues to use legacy calculation methods, ensuring no breaking changes for existing workflows.

✅ Extension compatibility: Changes are internal to LiteGraph slot position calculations and don't affect the extension API surface.

Positive Observations

🎯 Problem-focused solution: The PR directly addresses the stated issue of reroute-origin drags not snapping to the same visual slot centers as Vue nodes, with a surgical approach that touches only the necessary code paths.

🏗️ Code quality:

• Proper TypeScript typing with explicit Point annotations
• Consistent conditional logic pattern across all changes
• Meaningful variable names and clear intent
• Maintains existing error handling and fallback mechanisms

🔧 Implementation details:

• Smart use of indexOf to convert slot objects to indices where needed
• Proper handling of the result.index from findInputByType/findOutputByType methods
• Clean parameter renaming in getOutputPos (slot → outputSlotIndex) improves code clarity

Technical Analysis

The core change routes LiteGraph slot position queries through getSlotPosition(), which:

1. First attempts to retrieve DOM-tracked positions from layoutStore.getSlotLayout()
2. Falls back to node layout tree calculations if available
3. Finally falls back to original LiteGraph geometry calculations

This creates a single source of truth for slot positioning that prioritizes accuracy from DOM measurements while maintaining all existing fallback behavior.

Next Steps

✅ Ready for merge: This PR is well-implemented with no issues identified. The changes are minimal, focused, and follow established architectural patterns.

📋 Testing: Verify that reroute-origin drag snapping now matches Vue node hover behavior in manual testing.

---

This is a comprehensive automated review. The high code quality and surgical approach of this PR made it an exemplary implementation with no issues requiring correction.