www/test/vitest.setup.ts (1)

1-14: Duplicated matchMedia mock — consider extracting a shared helper.

This is an exact duplicate of the mock in test/vitest.setup.ts. If the mock shape evolves (e.g., adding addListener/removeListener), both files need to stay in sync. Consider extracting a shared helper function.

Also applies the same addListener/removeListener gap noted in test/vitest.setup.ts.

src/animation/JavascriptAnimate.tsx (1)

41-61: Add explicit return type annotation and SSR guard in useEffect.

Two items:

1. Per coding guidelines, function return values should be explicitly typed.
2. While useEffect doesn't run on the server, adding a defensive SSR guard in the effect body future-proofs against edge cases where Global.isSsr is set in a browser context (e.g., testing scenarios or universal apps that flip this flag).

Proposed fix

-function usePrefersReducedMotion() {
+function usePrefersReducedMotion(): boolean {
   const [prefersReducedMotion, setPrefersReducedMotion] = useState(() => {
     if (Global.isSsr) {
       return false;
     }
     return window.matchMedia('(prefers-reduced-motion: reduce)').matches;
   });
 
   useEffect(() => {
+    if (Global.isSsr) {
+      return undefined;
+    }
     const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
     const handleChange = () => {
       setPrefersReducedMotion(mediaQuery.matches);
     };
     mediaQuery.addEventListener('change', handleChange);
     return () => {
       mediaQuery.removeEventListener('change', handleChange);
     };
   }, []);
 
   return prefersReducedMotion;
 }

As per coding guidelines: "Type function parameters and return values explicitly."

src/polar/Radar.tsx (1)

111-115: JSDoc update looks good — minor grammar nit.

The tense is inconsistent: "will be disabled" (future) vs. "respects" (present). Consider aligning:

✏️ Suggested wording

-   * If set "auto", the animation will be disabled in SSR and respects the user's prefers-reduced-motion system preference for accessibility.
+   * If set to "auto", the animation will be disabled in SSR and when the user's system enables the prefers-reduced-motion preference (for accessibility).

src/animation/JavascriptAnimate.tsx (1)

41-68: Add an explicit return type and eliminate the eslint-disable comment.

1. Per coding guidelines, function return values in src/** should be explicitly typed: function usePrefersReducedMotion(): boolean.
2. The eslint-disable consistent-return on line 61 can be avoided by wrapping the body in a single guard so there's only one return path.

♻️ Suggested refactor

-function usePrefersReducedMotion() {
+function usePrefersReducedMotion(): boolean {
   const [prefersReducedMotion, setPrefersReducedMotion] = useState(() => {
     if (Global.isSsr) {
       return false;
     }
     if (!window.matchMedia) {
       return false;
     }
     return window.matchMedia('(prefers-reduced-motion: reduce)').matches;
   });
 
   useEffect(() => {
-    if (!window.matchMedia) {
-      return;
-    }
-    const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
-    const handleChange = () => {
-      setPrefersReducedMotion(mediaQuery.matches);
-    };
-    mediaQuery.addEventListener('change', handleChange);
-    // eslint-disable-next-line consistent-return
-    return () => {
-      mediaQuery.removeEventListener('change', handleChange);
-    };
+    if (window.matchMedia) {
+      const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
+      const handleChange = () => {
+        setPrefersReducedMotion(mediaQuery.matches);
+      };
+      mediaQuery.addEventListener('change', handleChange);
+      return () => {
+        mediaQuery.removeEventListener('change', handleChange);
+      };
+    }
+    return undefined;
   }, []);
 
   return prefersReducedMotion;
 }

As per coding guidelines: "Type function parameters and return values explicitly. Do not rely on implicit any or inference."

src/component/TooltipBoundingBox.tsx (4)

76-82: Calling setState during render — valid but fragile pattern.

This is the React-sanctioned "adjust state during rendering" pattern (analogous to getDerivedStateFromProps), so it works. However, it's easy to accidentally introduce an infinite loop if a future change makes the guard condition always true.

A slightly safer alternative is to move this into the existing useEffect on [props.coordinate?.x, props.coordinate?.y], which already fires when coordinates change:

♻️ Optional: move dismissal reset into the effect

   React.useEffect(() => {
+    setState(prev => (prev.dismissed ? { ...prev, dismissed: false } : prev));
+
     const handleKeyDown = (event: KeyboardEvent) => {
       if (event.key === 'Escape') {
         setState({
           dismissed: true,
           dismissedAtCoordinate: {
             x: props.coordinate?.x ?? 0,
             y: props.coordinate?.y ?? 0,
           },
         });
       }
     };
     document.addEventListener('keydown', handleKeyDown);
     return () => {
       document.removeEventListener('keydown', handleKeyDown);
     };
   }, [props.coordinate?.x, props.coordinate?.y]);

Then remove lines 76–82 entirely.

---

98-119: visibility on line 110 is dead code — always overridden on line 117.

In outerStyle, the object spread ...positionStyle is followed by an explicit visibility key, which overwrites whatever positionStyle.visibility was. This means the visibility set on line 110 inside positionStyle never reaches the final style object.

Either remove it from positionStyle (line 110) to avoid confusion, or remove the duplicate from outerStyle (line 117) if the intent is for positionStyle to be the single source.

♻️ Suggested fix — remove from positionStyle

         ...cssProperties,
         pointerEvents: 'none',
-        visibility: !state.dismissed && props.active && props.hasPayload ? 'visible' : 'hidden',
         position: 'absolute',
         top: 0,
         left: 0,
       };

---

58-74: Event listener is torn down and re-added on every coordinate change.

The useEffect depends on [props.coordinate?.x, props.coordinate?.y], so the keydown listener is removed and re-registered every time the tooltip moves. Since handleKeyDown only needs the current coordinates at the time the key is pressed, you could store coordinates in a ref and use an effect with an empty dependency array to register the listener once.

This is a minor optimisation — the current code is correct.

---

51-56: Missing JSDoc on the component and its props.

Per project guidelines, source files should include JSDoc comments (used to autogenerate API docs). TooltipBoundingBoxProps and TooltipBoundingBoxImpl lack any doc comments. Consider adding at least a brief JSDoc on the exported TooltipBoundingBox and the public props interface. As per coding guidelines: "JSDoc comments and TypeScript definitions in source files must be kept up-to-date as they are used to autogenerate API documentation via 'npm run omnidoc'."