You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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](https://www.notion.so/PR-5903-Use-layoutStore-slot-positions-for-node-slot-queries-fix-reroute-origin-node-snap-2816d73d36508184b297f46b39105545)
by [Unito](https://www.unito.io)
0 commit comments