A chart view starts a self-rescheduling requestAnimationFrame loop when it is shown. After the user moves between views several times the page grows steadily slower. What is going on and how do you fix it?

## Why the loop never stops on its own `requestAnimationFrame` registers a callback for exactly one frame. The continuous-animation idiom works by re-registering from inside the callback: ```js function loop() { drawChart(); requestAnimationFrame(loop); // books the next frame } requestAnimationFrame(loop); ``` Nothing in that code has a stopping condition. Removing the chart element from the document does not stop it; the callback is held by the browser's frame scheduler, not by the DOM node, and the closure keeps the node alive. Navigating away inside a single-page app does not stop it either, because there is no page unload. The only things that stop it are the callback declining to re-register, `cancelAnimationFrame`, or the page ceasing to exist. ## The accumulation Every time the view is shown, the setup code runs again and starts another independent loop. The loops do not know about each other. After n visits, each frame invokes n callbacks. Symptoms in order of appearance: - the frame budget fills up and the visible animation gets choppy, - CPU and battery use climb even when nothing appears to be moving, - memory grows, because each stale closure retains its element references, its data arrays and whatever else it captured, and none of it can be collected, - errors start appearing from callbacks operating on detached nodes or on state that has since been reset. The give-away when diagnosing is that the slowdown is proportional to how many times the view has been entered, and that it survives leaving the view. ## The fix: own the handle `requestAnimationFrame` returns a positive integer handle identifying that one pending registration. `cancelAnimationFrame(handle)` removes it. Because the loop re-registers every frame, the handle changes every frame, so store the newest one: ```js let handle = null; function start() { const loop = () => { drawChart(); handle = requestAnimationFrame(loop); }; handle = requestAnimationFrame(loop); } function stop() { if (handle !== null) { cancelAnimationFrame(handle); handle = null; } } ``` Every code path that shows the view must have a matching path that tears it down, and the teardown must call `stop()`. Passing a handle that has already fired, or one you already cancelled, does nothing at all — the call is safe to make unconditionally, which means the teardown path needs no cleverness. ## The re-entrancy trap One subtlety: cancelling only removes the *pending* registration. If teardown happens while the callback is mid-flight — for example the callback itself triggers something that tears the view down synchronously — the callback will still finish and its trailing `requestAnimationFrame` will book a fresh frame *after* your cancel ran. A boolean guard closes that hole: ```js let running = false; const loop = () => { if (!running) return; drawChart(); handle = requestAnimationFrame(loop); }; ``` Set `running = true` in start and `false` in stop, before the cancel. ## Idempotent start The mirror-image defect is calling `start()` twice for the same view — from two code paths, or a re-entered setup — which forks the loop into two branches sharing one handle variable, and now the cancel can only reach one of them. Make `start()` a no-op when a loop is already running. ## The design lesson Anything that registers ongoing work with the browser — frame callbacks, timers, event listeners, observers, subscriptions — has the same shape: acquiring it must return a way to release it, and the release must be wired into the same lifecycle that did the acquiring. A rAF loop is easy to overlook precisely because it looks like a one-shot call rather than an ongoing registration.