fix(frontend): place new nodes in nearest free space instead of overlapping#19
Open
LukasHirt wants to merge 1 commit into
Open
fix(frontend): place new nodes in nearest free space instead of overlapping#19LukasHirt wants to merge 1 commit into
LukasHirt wants to merge 1 commit into
Conversation
mzner
previously approved these changes
Jul 24, 2026
…apping Extract the "+" button's new-node position calculation into a pure, testable computeNewNodePosition() helper that checks existing node positions and cascades downward in fixed steps until it finds a slot that doesn't overlap another node, instead of always placing the node at a fixed offset from its source. Signed-off-by: Lukas Hirt <info@hirt.cz>
LukasHirt
force-pushed
the
fix/node-placement-collision
branch
from
July 24, 2026 20:46
494c8fa to
8c02aac
Compare
mzner
self-requested a review
July 24, 2026 20:47
mzner
approved these changes
Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When adding a node via the "+" button, the new node's position was always computed as a fixed offset from its source node:
{ x: source.x + 260, y: source.y }. If a node already occupied (or nearly occupied) that spot — e.g. the user clicked "+" on the same source twice — the new node landed directly on top of the existing one instead of stacking below it.Before
New node placement after a source node was a single fixed calculation with no awareness of existing nodes, so repeated "+" clicks on the same source stacked nodes exactly on top of each other.
After
Placement now goes through a new pure helper,
computeNewNodePosition(existingNodes, sourceNode)infrontend/src/utils/nodeLayout.ts:source.x + 260, source.y) for the common case.min-widthfromstyles/canvas.cssand the existing120px vertical spacing constant), it steps the candidate down by120px and re-checks, cascading further down as needed until it finds a free slot.nodes.length.onPickNodeType()infrontend/src/views/WorkflowBuilder.vuenow delegates to this helper instead of doing the inline calculation.Test plan
frontend/tests/unit/nodeLayout.spec.tscovering: no collision, one node occupying the candidate spot, two nodes already stacked (cascades two steps down), and unrelated far-away nodes not affecting placement — confirmed they failed before implementation (module didn't exist).computeNewNodePositionand confirmed all 4 new tests pass.npm run test:unit— full suite passes (3 files, 8 tests).npm run check:types— no errors.npm run lint— no errors.Scoped only to this positioning logic — no changes to the "+" button's CSS/alignment, node categorization, the config modal, or flow validation.
🤖 Generated with Claude Code