#5933·xyflow

Connection dragging silently stops working after a node remounts under React.StrictMode (no error, no connection line, only a hard page reload recovers)

Author: bife34Created Jul 31, 2026Updated Aug 10, 2026

What platform were you using when you found the bug?

Environment

  • @xyflow/react 12.11.2
  • React 18.3.1, react-dom 18.3.1
  • Vite dev server, <React.StrictMode> wrapping the app root
  • Windows 11, Chrome

Repro

  1. Render a <ReactFlow> canvas with custom nodes using <Handle> (+ optionally <NodeResizer>) inside a route/component that gets mounted via client-side routing (e.g. react-router-dom).
  2. On first mount, drag a connection from one node's handle to another — works fine, connection line renders while dragging, onConnect fires.
  3. Navigate away from that route (unmount the <ReactFlow> subtree) and navigate back (remount it fresh — same component, new instance).
  4. Try dragging a connection from a handle on a newly-added node again.

Expected: Same behavior as step 2 — connection line follows the cursor, onConnect fires on drop.

Actual: Nothing happens. No connection line appears at all while dragging (so the handle's pointer-down isn't registering as starting a connection), and no console error/warning is printed. The only way to recover is a full page reload — remounting the route again via client-side navigation alone does not fix it.

Workaround found: Removing <React.StrictMode> from the app root (ReactDOM.createRoot(...).render(<App/>) without the StrictMode wrapper) makes the bug disappear entirely — connections work reliably across any number of route-based mount/unmount/remount cycles, no hard reload needed.

Hypothesis: @xyflow/react sets up per-node measurement/handle registration (via ResizeObserver, per the source in dist/esm/index.mjs) during mount effects. React 18 StrictMode intentionally double-invokes mount → cleanup → mount for every freshly-mounted subtree in dev mode, not just on the app's very first ever mount — so every remount of the <ReactFlow> tree goes through that double-invoke cycle. Whatever internal setup registers a node's handles for connection-dragging doesn't appear to fully re-establish itself after that double-invoke, but only on a remount of an already-running page — a component's very first mount (right after a real page load) isn't affected the same way, suggesting some piece of setup/teardown isn't idempotent when run back-to-back against a browser environment that isn't completely fresh.

I don't have a minimal repro isolated to just this library yet (found it while debugging a full app), but wanted to flag the shape of the bug in case it's a known StrictMode rough edge, or in case someone with more context on the internals recognizes the exact effect responsible. Happy to help narrow it down further if useful.

Claude Feedback hope it helps u guys,

Live code example

No response

Describe the Bug

Nodes connections failing

Steps to reproduce the bug or issue

Repro

  1. Render a <ReactFlow> canvas with custom nodes using <Handle> (+ optionally <NodeResizer>) inside a route/component that gets mounted via client-side routing (e.g. react-router-dom).
  2. On first mount, drag a connection from one node's handle to another — works fine, connection line renders while dragging, onConnect fires.
  3. Navigate away from that route (unmount the <ReactFlow> subtree) and navigate back (remount it fresh — same component, new instance).
  4. Try dragging a connection from a handle on a newly-added node again.

Expected: Same behavior as step 2 — connection line follows the cursor, onConnect fires on drop.

Actual: Nothing happens. No connection line appears at all while dragging (so the handle's pointer-down isn't registering as starting a connection), and no console error/warning is printed. The only way to recover is a full page reload — remounting the route again via client-side navigation alone does not fix it.

Expected behavior

the nodes should connect, im not sure if its because of the load state or not, but this it did solve the issue.

Screenshots or Videos

No response

Additional context

No response