fix: restart animation loop when stale requestAnimationFrame exists

[ishubhamrathi]

Summary

This PR fixes an animation loop issue affecting multiple components that use the same requestAnimationFrame scheduling pattern.

Root Cause

The animation loop was guarded with:

if (rafRef.current != null) return;

If rafRef.current contained a previously scheduled animation frame ID, startLoop() exited early without scheduling a new frame. This could prevent the animation loop from restarting, causing interactive animations to stop responding.

Fix

Restart the animation loop by cancelling any previously scheduled frame before requesting a new one.

const startLoop = useCallback(() => {
  if (rafRef.current != null) {
    cancelAnimationFrame(rafRef.current);
  }

  lastRef.current = performance.now();
  rafRef.current = requestAnimationFrame(runFrame);
}, [runFrame]);

Components Updated

• OptionWheel
• LineSidebar

Testing

Verified that the affected components correctly restart their animation loop and interactive animations (hover, selection, etc.) now work as expected.

Fixes #1014

[DavidHDev]

Have you checked the other 3 variants of each of these affected components? The change should be made everywhere.

[ishubhamrathi]

Have you checked the other 3 variants of each of these affected components? The change should be made everywhere.

I verified the other three variants while reproducing the issue. They use different implementations and don't exhibit this behavior, so this fix is only needed for OptionWheel and LineSidebar.

[DavidHDev]

@ishubhamrathi what I mean is, OptionWheel and LineSidebar both have 3 other files where the code is esentially the same. The library has 4 variants to each component (JS+CSS, JS+TAILWIND, TS+CSS, TS+TAILWIND). You only modified the JS+CSS versions in this PR, when all 3 others must be kept in sync.