React Animation Cleanup: Why Ghost Listeners and Timelines Survive

A React animation can be gone from the screen and still very much alive.

The section unmounted. The route changed. The hero disappeared. Yet somewhere in the runtime, a resize listener is still measuring old geometry. A requestAnimationFrame loop is scheduling another frame. An observer is still watching. A ScrollTrigger is still registered. Navigate back and the setup runs again. Now you have two of everything.

The practical fix is simple to state: put every external resource an interaction creates inside a clear lifecycle, then stop or undo every one of those resources when that lifecycle ends. In React, that usually means pairing Effect setup with symmetrical cleanup and using an animation library's scoped cleanup primitives where they exist.

The difficult part is noticing everything the interaction actually started.

React animation cleanup is not just return () => timeline.kill(). Animation code routinely crosses React's boundary into browser events, observers, timers, animation engines, scroll infrastructure and continuous render loops. React treats an Effect as synchronization with an external system: when dependencies change, it runs the previous cleanup before the new setup, and it runs cleanup again when the component is removed.

A better mental model is:

Setup → Own → Dispose → Verify

The last word matters. A cleanup function that looks plausible is not the same thing as proving the ghost is gone.

The Animation Can Disappear While Its Work Keeps Running

Removing a React component removes the rendered UI that component owned. It does not automatically remove an event listener you registered manually on window. It does not know that your ResizeObserver should disconnect or your RAF loop should stop scheduling itself. Third-party animation libraries may clean resources they own, but they cannot infer responsibility for arbitrary browser work created beside them.

Here is a deliberately broken example:

1"use client";2 3import { useEffect } from "react";4 5export default function LeakyPointerLoop() {6  useEffect(() => {7    function handlePointerMove(event) {8      console.log("pointer:", event.clientX);9    }10 11    function tick() {12      console.count("animation frame");13      requestAnimationFrame(tick);14    }15 16    window.addEventListener("pointermove", handlePointerMove);17    requestAnimationFrame(tick);18  }, []);19 20  return <div>Move the pointer, then remove this component.</div>;21}

It renders. It reacts to the pointer. The frame loop runs.

It also has no cleanup.Remove the component and the listener remains registered. The RAF callback keeps scheduling its successor. Mount the component again and you add another listener and another loop.The runtime begins collecting souvenirs.

The fixed version owns both resources:

1"use client";2 3import { useEffect } from "react";4 5export default function PointerLoop() {6  useEffect(() => {7    let frameId = 0;8    let active = true;9 10    function handlePointerMove(event) {11      console.log("pointer:", event.clientX);12    }13 14    function tick() {15      if (!active) return;16 17      console.count("animation frame");18      frameId = requestAnimationFrame(tick);19    }20 21    window.addEventListener("pointermove", handlePointerMove);22    frameId = requestAnimationFrame(tick);23 24    return () => {25      active = false;26      window.removeEventListener("pointermove", handlePointerMove);27      cancelAnimationFrame(frameId);28    };29  }, []);30 31  return <div>Move the pointer, then remove this component.</div>;32}

Cancelling the stored frame stops the pending request. The active guard prevents additional scheduling if the callback is entered after cleanup. It is defensive; it does not replace tracking the latest request ID correctly.The important difference is architectural, not syntactic.

Setup creates two pieces of external work. Cleanup disposes of those same two pieces of work.

Before:

mount → listener + RAF loop → remove component → listener + RAF continue

After:

mount → listener + RAF loop → cleanup → remove listener + cancel loop → zero section-owned work

That is React animation cleanup in its useful form.

React Gives Every Side Effect a Lifetime

React's Effect model already provides the correct boundary. The common mistake is treating cleanup as a final unmount chore instead of the other half of setup.

An Effect can run when a component enters the tree. If its dependencies later change, React first runs the previous cleanup and then starts setup again with the new values. When the component is removed, React runs cleanup one final time. React explicitly recommends thinking in terms of independent setup/cleanup processes whose teardown mirrors their setup.That distinction matters because animation work is often rebuilt without the component disappearing.

A breakpoint changes. A measured width changes. A prop selects a different interaction state. Reduced-motion preferences send the component down another path. An animation sequence is reconstructed because one of its inputs changed.

If cleanup only works when you mentally picture “unmount,” you will miss bugs caused by resynchronization.

Consider an observer-driven state change:

1"use client";2 3import { useEffect, useRef } from "react";4 5export default function VisibilityProbe() {6  const sectionRef = useRef(null);7 8  useEffect(() => {9    const section = sectionRef.current;10    if (!section) return;11 12    const observer = new IntersectionObserver(13      ([entry]) => {14        section.dataset.visible = String(entry.isIntersecting);15      },16      { threshold: 0.25 }17    );18 19    observer.observe(section);20 21    return () => {22      observer.disconnect();23    };24  }, []);25 26  return (27    <section ref={sectionRef} data-visible="false">28      Observe me29    </section>30  );31}

Nothing is left implied. The element exists through a ref. The callback exists. The observer is attached to that element. The same Effect disconnects it.That symmetry scales better than memorising cleanup commands.

Strict Mode is Showing You the Leak, Not Creating it

A familiar debugging story goes like this: an animation appears to initialize twice in development, Strict Mode is enabled, and Strict Mode gets blamed for breaking the page.Usually it is the witness.

When Strict Mode applies to the relevant tree, React performs an additional Effect setup-and-cleanup cycle in development specifically to surface missing teardown. Those checks do not apply to the production build.

That behavior is particularly useful for imperative animation code. A setup with incomplete teardown may look perfectly healthy when it runs once. An additional setup → cleanup → setup cycle makes a leftover listener, trigger or subscription much harder to hide.

If Strict Mode leaves two listeners after the component settles, the useful question is : “Why didn't cleanup undo the first setup?”

At the end of setup → cleanup → setup, you should have one active instance of everything the mounted component needs. Not two.

Audit Everything the Animation Starts

A production interaction is rarely one object called “the animation.”

A cursor may have pointer listeners plus a RAF interpolation loop. A scroll section may combine a GSAP timeline, ScrollTrigger and resize measurement. A reveal may need only an observer and a CSS class. A WebGL scene may carry a continuous renderer, textures, geometry and resize handling.

Different interaction classes deserve different teardown work.

The final column turns cleanup from intention into a test.If a component creates a resource, that component- or a hook clearly owned by it-should normally be able to dispose of it without searching the rest of the application.

Global destruction is usually a warning sign. Killing every trigger in an application because one section disappeared may remove your duplicate animation, but it also tells you the local interaction does not know what it owns.

Local setup deserves local teardown.

GSAP: Use a Scope You Can Actually Revert

GSAP provides a strong answer to the ownership problem through gsap.context() and its React-specific useGSAP() hook.

GSAP documents useGSAP() as a React-oriented wrapper that uses gsap.context() for cleanup. GSAP animations, ScrollTriggers and other supported GSAP objects created while the hook executes can be recorded in that context and reverted when the hook is torn down.

1"use client";2 3import { useRef } from "react";4import gsap from "gsap";5import { ScrollTrigger } from "gsap/ScrollTrigger";6import { useGSAP } from "@gsap/react";7 8gsap.registerPlugin(ScrollTrigger, useGSAP);9 10export default function FeatureSection() {11  const sectionRef = useRef(null);12 13  useGSAP(14    () => {15      gsap.from(".feature-title", {16        y: 32,17        opacity: 0,18        duration: 0.8,19        scrollTrigger: {20          trigger: ".feature-title",21          start: "top 80%",22        },23      });24    },25    { scope: sectionRef }26  );27 28  return (29    <section ref={sectionRef}>30      <h2 className="feature-title">A scoped feature section</h2>31    </section>32  );33}

The useful part is the ownership boundary: the feature section creates its animation, the context records the GSAP work created inside that execution, and teardown can revert the work belonging to that context.

Read GSAP's current React integration guidance

Dependency changes need one extra decision

Do not assume useGSAP() mirrors useEffect cleanup semantics for dependency updates by default.

GSAP currently documents revertOnUpdate as false by default. If you give useGSAP() dependencies, changing one of them does not automatically revert the existing GSAP context on every update. If your interaction should tear down the previous GSAP work before rebuilding from the new dependency values, set revertOnUpdate: true.

1useGSAP(2  () => {3    gsap.to(".panel", {4      x: endX,5    });6  },7  {8    dependencies: [endX],9    scope: sectionRef,10    revertOnUpdate: true,11  }12);

That distinction matters in an article about lifecycle ownership. React's Effect rules are not a licence to assume every third-party React hook implements dependency teardown identically.

Late-created GSAP animations need to join the context

There is another boundary worth knowing.Animations created later inside click handlers, timers or other deferred callbacks are created after the initial useGSAP() execution. GSAP documents contextSafe() as the way to make those later functions record GSAP work in the same context.

1"use client";2 3import { useRef } from "react";4import gsap from "gsap";5import { useGSAP } from "@gsap/react";6 7gsap.registerPlugin(useGSAP);8 9export default function InteractiveCard() {10  const cardRef = useRef(null);11 12  const { contextSafe } = useGSAP({13    scope: cardRef,14  });15 16  const handleClick = contextSafe(() => {17    gsap.to(".card-face", {18      rotation: "+=8",19      duration: 0.3,20      yoyo: true,21      repeat: 1,22    });23  });24 25  return (26    <article ref={cardRef}>27      <button className="card-face" onClick={handleClick}>28        Nudge card29      </button>30    </article>31  );32}

If you manually register a browser event listener, however, you still own that listener. GSAP explicitly calls out manual listener removal in its React guidance.

The abstraction cleans what it owns. You own the rest.

Motion Shows the Other Side of the Design Space

Not every animation API asks you to manage animation disposal in the same way.

Motion's useAnimate gives a component a scoped ref plus an animate function. Selectors passed through that function are scoped to the component, and Motion documents automatic cleanup for animations started through that animate function when the component is removed.

1"use client";2 3import { useEffect } from "react";4import { useAnimate } from "motion/react";5 6export default function MotionList() {7  const [scope, animate] = useAnimate();8 9  useEffect(() => {10    animate("li", { opacity: 1, y: 0 });11  }, [animate]);12 13  return (14    <ul ref={scope}>15      <li style={{ opacity: 0, transform: "translateY(12px)" }}>16        First item17      </li>18      <li style={{ opacity: 0, transform: "translateY(12px)" }}>19        Second item20      </li>21    </ul>22  );23}

Read Motion's useAnimate documentation

That automatic cleanup does not extend to unrelated resources you create manually. A raw pointer listener, observer or custom subscription is still your responsibility.There is no universal React animation cleanup command.

How to Catch a Ghost Animation Before It Ships

A return () => { ... } block proves cleanup code exists. It does not prove that you cleaned the right thing.

Use a repeatable diagnostic pass:

1. Establish the expected baseline for the section's active resources.
2. Exercise the full interaction: scroll, pointer movement, clicks, delayed callbacks.
3. End the owner's actual lifecycle or trigger the dependency change that should replace its current setup.
4. Probe the relevant resource after teardown.
5. Mount or initialize the interaction again.
6. Confirm active work returns to the expected baseline instead of accumulating.
7. Repeat through Strict Mode, responsive variants and reduced-motion branches where those paths affect setup.

Do not rely only on cumulative logs. console.count("setup") and console.count("cleanup") can tell you that lifecycle functions ran, but matching totals do not prove some unrelated listener or loop did not survive.

For resources you control, an active-instance probe is more useful:

1let activePointerLoops = 0;2 3export function getActivePointerLoops() {4  return activePointerLoops;5}6 7export function startPointerLoop() {8  let active = true;9  let frameId = 0;10 11  activePointerLoops += 1;12 13  function tick() {14    if (!active) return;15 16    frameId = requestAnimationFrame(tick);17  }18 19  frameId = requestAnimationFrame(tick);20 21  return function stopPointerLoop() {22    if (!active) return;23 24    active = false;25    cancelAnimationFrame(frameId);26    activePointerLoops -= 1;27  };28}29Used from an Effect:30useEffect(() => {31  const stop = startPointerLoop();32 33  console.log("active pointer loops:", getActivePointerLoops());34 35  return () => {36    stop();37    console.log("active pointer loops:", getActivePointerLoops());38  };39}, []);

In development, this is a diagnostic instrument, not application architecture. The point is to ,measure current active work, not merely how many times setup has ever happened.

After teardown, the count for that section-owned resource should return to its expected baseline.The exact instrumentation depends on the resource. Browsers do not offer one universal counter for event listeners, observers, RAF loops, GSAP contexts and arbitrary subscriptions.

Debug the owner, not the entire universe.

Route Changes Are Useful Tests-When They Actually End the Lifetime

“Navigate away and back” is useful advice only if navigation actually ends the lifecycle you are testing.

In the Next.js App Router, layouts are explicitly persistent across navigation: they preserve state, remain interactive and do not rerender on navigation. A component living inside such a retained layout therefore should not be expected to unmount simply because a child route changed.

Read Next.js's current layouts and pages documentation

If your animated product section belongs to a page that disappears, navigation can be a good teardown test.

If an animated header belongs to a persistent layout, navigation between child pages is not an unmount test for that header. Its relevant lifecycle might instead be a dependency change, mode transition or eventual removal of the layout.

The question is :

“Did the owner reach the point where these resources should stop belonging to the runtime?”

For the larger question of how to divide page-level and section-level scroll animation ownership, keep that architecture discussion separate. Read How to Build Scroll Animations in React Without Turning the Page Into a Timeline Mess

This page has a narrower job: once you know who owns the interaction, make sure its work does not outlive that ownership.

Reduced Motion and Responsive Variants Need Cleanup Too

Lifecycle bugs are not confined to the default desktop path.

Suppose a component creates a continuous pointer interaction on desktop but switches to a static treatment on mobile. Or a reduced-motion preference replaces a scroll-driven transform with an immediately visible state. If those modes can change while the application is running, the previous mode's resources need to be disposed of before the new mode takes control.

Test the transition, not only each endpoint:

desktop setup → desktop cleanup → mobile setup

animated setup → animated cleanup → reduced-motion setup

If a listener from the first mode survives after the second has taken ownership, two interaction models are now disagreeing over the same component.

Reduced motion is also not the complete accessibility story. Motion-heavy UI still needs readable fallbacks, sensible keyboard and focus behavior, and input assumptions that work beyond pointer devices.

Cleanup keeps the runtime coherent. It does not replace interaction design judgment.

Production Motion Needs an Owner

Real React and Next.js sites have route transitions, persistent layouts, responsive states, content changes, reduced-motion paths and several effects sharing one browser.

Production quality depends less on whether an easing curve looks expensive and more on whether an interaction can answer a few operational questions:

• What creates it?
• What keeps running?
• What changes when its inputs change?
• What survives?
• What gets restored?
• What owns teardown?
• How do you prove active work does not accumulate?

Sometimes the right answer is GSAP. Sometimes Motion's scoped API is enough. Sometimes CSS carries the interaction with less runtime responsibility. Sometimes the page does not need motion at all.Motion has to earn its runtime.

Hyperiux Vault uses a source-first installation model: selected effect files land in the project where teams can inspect and adapt them, while dependencies vary by effect rather than being hidden behind one universal runtime.

Source ownership does not automatically make cleanup correct.It gives you somewhere concrete to verify it. Before integrating an interaction, inspect what external work it creates. Find the client boundary. Check its dependencies. Identify listeners, observers, timers, triggers and continuous loops. Run the lifecycle test. Verify responsive and reduced-motion paths do not leave their previous mode behind.

Then ship it.Because the best sign that your animation cleanup works is wonderfully boring:

You leave. Nothing follows you.

Browse Hyperiux Vault effects and inspect the implementation, dependencies and lifecycle before integrating one into your project