name: react-move-optimizer description: Audit and optimize React Move (react-move, NodeGroup/Animate data-driven animations ~3.5kb by sghall) usage in codebases — re-render-per-frame costs with large NodeGroup arrays, data immutability pitfalls (data prop must change identity), timing/interpolation configuration (numeric-only default, d3-interpolate for colors/paths), the no-arrays/no-'timing'-keys state rules, leave transitions keeping nodes in the DOM, interrupted transitions, and modernization options given the unmaintained status (React 18/19 compatibility concerns, motion/react or react-spring alternatives). Report with evidence and a plan approved before edits. Use when the user mentions react-move, NodeGroup, Animate components, data-driven React animations in older dashboards/charts, or reports broken two/three.x react-move upgrades -- even if they don't say "optimize".

React Move Optimizer

Audit how a codebase uses React Move, report what is slow or risky, agree a plan, then fix. React Move (NodeGroup, Animate) animates by updating state on every animation frame, so cost scales with how many nodes are animated and how often the render closes over changing data. Two structural facts drive the audit: the library is effectively unmaintained (six.x-on-React-18/19 worth testing) and the current API is hand-rolled for performance (numeric-only interpolation by default; every data change re-runs the transition pipeline). Report first, plan approved, then edit — and propose modernization only as its own, separately-approved item.

Workflow

1. Scope (quick)

• Find project root (package.json with react-move). Record: react-major (16/17/18/19), react-move version, d3-interpolate presence.
• Run python <skill-dir>/scripts/audit.py <project-root> [--json] — inventories NodeGroup/Animate usage, flags per-frame render hot spots (big children maps, closures recreated each node render), missing interpolation props for color/path strings (they silently don't interpolate numeric-only), data mutation patterns that defeat transitions, large leave durations, React 18/19 compat flag.

2. Audit

The script net leads; you confirm by reading the animation code. Load references as fit:

Checks only you can do (by reading or profiling):

• The scale: which chart/visual is animated at what rate (how many nodes, how often data updates: per frame Everett, per data-poll, per user click?).
• Whether colors/paths/SVG transforms are animated — numeric interpolation only in 6.x without an interpolation prop: these fail silently or with a swap, not a smooth transition.
• What hooks fire each frame — event handlers, setState from parent re-render in a NodeGroup children closure etc. — the whole this file in a profiler.

Profiling beats assertion: if a dashboard animation is slow, React DevTools or the Records panel's timing tells you where. Report measured values.

Mark findings Confirmed or Suspected.

3. Report

Fill in assets/report-template.md, save as REACT_MOVE_REPORT.md in the project root; group by correctness (silent interpolation failures), performance, maintenance risk.

4. Plan — stop for approval

1. Quick wins — data immutability fixes (mutations break transitions), correct keyAccessor, timing pruning (smaller duration on update), cheap color swaps via two-element numeric pairs.
2. Structural — hoist per-node closures out of the render loop; memoize scale computations; move exit/enter duration to sane values; kill accidental Animate re-mounts via keys.
3. Modernization (separate item) — given the unmaintained status: pinning a fork, testing on the current React, or replacing NodeGroup with a modern alternative — opt-in only, is its own step with rollback. Each step: files, effect, verify, rollback. Let the user drop/reorder.

5. Fix

Approved items only, smallest first. After each group run the project's typecheck/lint and exercise the animation (enter/update/leave + interrupt mid-transition). Returning React: the render-closure shape is delicate — one look at the diff before declaring success.

6. Verify and wrap up

• Re-run the profiler or recount renders (React DevTools "highlight updates") — the before/after change is usually frame-render count per data update, not bundle bytes.
• Confirm enter/update/leave/interrupt behave on the affected visual; check with duration/delay including interruption cases mid-transition.
• Report delta honestly (renders-per-update before/after, or "couldn't measure"); deferred items + next step.

Principles

• Every frame is a render. NodeGroup/Animate express animation as state that changes per frame; the fix for jank is fewer nodes/mutations/heavy closures, not "more memo".
• Data identity is the transition trigger. Deep-equal data won't animate; mutated data will corrupt the node map. Preach strictly-honest data immutability before touching anything else.
• Numeric-only by default. The 6.x built-in interpolator handles numbers; colors/paths need the interpolation prop and d3-interpolate. Silent flatness is a common "animation is broken" mystery.
• Leave transitions hold DOM. Exits animate through their full duration while keeping nodes mounted — long leave timings on changing lists are memory and jank costs.
• Modernization is a product call. The library's decade-old last release is a maintenance fact; propose motion/react/react-spring swaps as opt-in items with per-visual verification, never as silent rewrites.
• Show evidence. Frame-level performance claims need numbers (count renders per update / recorded traces); if not measureable at the current scope, say so.