Skip to content

fix: let a mind map close back up when a node is deleted (#513) - #522

Merged
vibhavkatre merged 1 commit into
mainfrom
fix/mindmap-delete-reflow-513
Aug 16, 2026
Merged

fix: let a mind map close back up when a node is deleted (#513)#522
vibhavkatre merged 1 commit into
mainfrom
fix/mindmap-delete-reflow-513

Conversation

@vibhavkatre

Copy link
Copy Markdown
Collaborator

Deleting two of three child nodes left the last one where the other two had pushed it, instead of moving back toward its parent.

Cause

Adding a node shoves its siblings aside and re-flows the tree — the auto-tidy of #273. Deleting one had no matching call, so the survivors kept the spacing of a tree they were no longer in.

Verified before building it

The issue asked to confirm the scope, since the report also asked for level-spacing logic. Reflowing on delete is enough: mindmapLayoutPatches already spaces a level against the real measured boxes (#427 item 8), so no layout work was needed — the layout was simply never asked to run. The added test pins the numbers: the survivor sat 65.5px off the root's centre line before and after the delete; it now moves in.

The fix

One settle step that every delete path routes through, so it does not matter how a node leaves:

Path Reached by
deleteMindmapSubtrees Delete on a selected mind-map node
removeShapes plain shape delete
removeSelectionOrIds mixed selection delete
removeWhiteboardSelection delete on a unified canvas

Two details the issue called out, both handled:

  • The anchors are read before the removal. A node that is already gone cannot name the tree it was in, so the surviving parents of the departing nodes are collected first. A deleted root contributes no anchor, which is correct — its whole tree left with it, so there is nothing to close up.
  • Several nodes reflow once, not per node. reflowTree settles a whole tree from any one member, so N members of one tree would be N identical re-flows. Trees already settled are tracked by their component set. fitMindmapNodes had the same per-id loop and now shares the deduped helper.

The settle runs inside the caller's commit(), so delete-and-settle is one undo step.

Also fixed in passing

deleteMindmapSubtrees filtered shapes and connectors but never state.selection, so deleted ids stayed selected. The shared removal it now calls clears them. Covered by a test.

Tests

Six, in useDiagramStore.freefloating.test.js. Three of them fail on main:

Full suite green: 1458 tests.

Closes #513

🤖 Generated with Claude Code

Adding a node shoves its siblings aside and re-flows the tree (#273). Deleting
one did not, so the survivors kept the spacing of a tree they were no longer in
— delete two of three children and the last one stayed where the other two had
pushed it.

Every delete path now routes through one settle step, so it does not matter
whether a node leaves by the mind-map Delete key, a plain shape delete, or a
mixed whiteboard selection. The trees to settle are read BEFORE the removal —
a node that is already gone cannot name the tree it was in — and each distinct
tree re-flows once however many of its nodes went. A deleted root contributes
nothing, which is right: its whole tree left with it.

The settle runs inside the caller's commit(), so delete-and-settle is one undo
step.

deleteMindmapSubtrees also left the deleted ids in state.selection; the shared
removal it now calls clears them.

No new layout logic. The existing balanced layout already spaces a level by the
real boxes — it was only never asked to run.

Closes #513

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@vibhavkatre
vibhavkatre merged commit b02828e into main Aug 16, 2026
3 checks passed
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.

[Canvas][Bug] Deleting a mind-map node does not re-flow the tree

2 participants