Fix drag position jump with memoized layout components

[mattgperry]

Summary

• Fixes drag position jumping when sibling layout changes happen while a memoized component (e.g. Ant Design Tree's rc-tree) is being dragged
• When a dragged component is wrapped in React.memo, parent state changes don't trigger its willUpdate(), leaving the projection system without a snapshot — so layout compensation is silently skipped
• The fix marks animation-blocked (dragged) nodes as layout-dirty before each update cycle and uses their previous layout as the snapshot, ensuring they always participate in measurement and receive correct drag compensation

Bug

Reported in #3169: dragging a file in an Ant Design Tree causes the element to jump to the wrong position when hovering over folders. The root cause is that rc-tree internally memoizes tree nodes — when a sibling's state changes (e.g., folder hover highlight), the dragged node doesn't re-render, so willUpdate() is never called. Without a snapshot, notifyLayoutUpdate() returns early and the drag's didUpdate listener never fires.

Fix

In create-projection-node.ts update(), before the transform reset step, iterate all nodes and for any that are isAnimationBlocked (set during drag) with a stale/missing snapshot:

1. Copy the previous layout as the snapshot
2. Set isLayoutDirty = true and shouldResetTransform = true

This ensures resetTransform() → updateLayout() → notifyLayoutUpdate() all process the node, computing the correct layout delta and emitting the didUpdate event for drag compensation.

Test plan

• New Cypress E2E test: memoized drag component + sibling DOM insertion during drag
• Test fails without fix, passes with fix (verified on both React 18 and React 19)
• All 91 Jest test suites pass (762 tests)
• All motion-dom tests pass (404 tests)
• yarn build succeeds

Fixes #3169

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR fixes a drag position jump that occurs when a memoized layout component (e.g., rc-tree nodes in Ant Design) is being dragged and sibling layout changes occur. Because React.memo prevents re-renders, the projection node's willUpdate() is never called, leaving node.snapshot undefined; notifyLayoutUpdate then exits early and the drag's didUpdate compensation is never applied.

The fix introduces ensureDraggedNodesSnapshotted, called at the start of the update() write-cycle. For any node that is animation-blocked (dragged) but has no snapshot (!isLayoutDirty), it synthetically creates one by assigning node.snapshot = node.layout (the previous measured layout), then marks the node dirty so that resetTransform → updateLayout → notifyLayoutUpdate all process it normally.

Key implementation details:

• Object reference semantics are correct: updateLayout replaces node.layout with a freshly allocated Measurements object, so node.snapshot still refers to the pre-update layout after measurement — exactly the "before" state needed to compute layout deltas.
• The guard !node.isLayoutDirty reliably distinguishes memoized nodes (no willUpdate → no dirty flag → no snapshot) from nodes that did re-render.
• isAnimationBlocked is exclusively set by VisualElementDragControls, so the fix is tightly scoped to drag interactions.

All existing tests pass and new E2E tests validate the fix across React 18 and 19.

Confidence Score: 5/5

• This PR is safe to merge — the fix is tightly scoped to animation-blocked nodes that lack snapshots, with no impact on the broader projection pipeline.
• The core fix is sound and well-implemented. It correctly uses object reference semantics (updateLayout replaces node.layout with a new object while snapshot retains the pre-update reference), the guard conditions reliably target only memoized drag nodes, and isAnimationBlocked is exclusively set during drag. All existing tests pass (91 Jest suites, 404 motion-dom tests) and new E2E tests validate the fix on both React 18 and 19. Code inspection shows no issues with the implementation.
• No files require special attention.

_{Last reviewed commit: 8c977b1}