medium

scroll과 resize 이벤트에 findAndHighlight 함수를 직접 연결하면 이벤트가 발생할 때마다 getBoundingClientRect가 호출되어 성능 저하를 유발할 수 있습니다. 특히 스크롤 시 잦은 reflow는 UI 버벅임(jank)의 원인이 될 수 있습니다. lodash-es가 이미 의존성에 있으므로 throttle 함수를 사용해 이벤트 핸들러의 호출 빈도를 조절하여 성능을 개선하는 것을 권장합니다.

// 예시 (lodash-es/throttle 사용)
import { throttle } from 'lodash-es';
// ...
useEffect(() => {
 findAndHighlight();
 if (!highlightedPart) return;
 const throttledFindAndHighlight = throttle(findAndHighlight, 100);
 // Re-calculate position on scroll/resize
 window.addEventListener('scroll', throttledFindAndHighlight, true);
 window.addEventListener('resize', throttledFindAndHighlight);
 return () => {
 window.removeEventListener('scroll', throttledFindAndHighlight, true);
 window.removeEventListener('resize', throttledFindAndHighlight);
 };
}, [highlightedPart, findAndHighlight]);

You can also use ResizeObserver.

ResizeObserver only detects changes to the element's size. However, when used in a menu or non-modal form, scrolling may occur. In such cases, as ResizeObserver cannot detect position changes, we implemented it by adding scroll and resize event listeners.

Since scroll and resize are separate events, comparing ResizeObserver and scroll doesn't seem particularly meaningful. We're still adding separate event handlers for resize and scroll!

I mentioned ResizeObserver because I wondered if we could at least improve things for resize!

Good catch. I was mixing scroll and resize concerns in the previous explanation.

I've updated this so scroll is removed, and resize-driven recalculation now uses
ResizeObserver instead of the window resize event. I also added MutationObserver
because OverlayPrimitive mount/unmount can invalidate the Trigger highlight without any
resize.

You can also use ResizeObserver.

I understand that using memo to memoize a component prevents the component itself from re-rendering. Is this part okay?

After revisiting this, I decided that memo at the PartButton level was not the right
optimization point, so I removed it.

Instead, I memoized AnatomyPanel so that parent re-renders caused by hover state changes,
which only affect the preview highlight, do not propagate through the entire panel subtree.

This works because the props passed to AnatomyPanel are stable in the current structure:

• panelProps is wrapped with useMemo
• the handlers are kept stable with useCallback
• availableParts only changes reference when its actual contents change

As a result, hover-only updates do not re-render AnatomyPanel, and its child PartButtons
are skipped together.
When values that actually affect the panel UI, such as selectedPart or availableParts,
change, a re-render is still intentional.

It might be worth considering whether this element should actually be a button. Currently, it directly handles all mouse events, and clicking it doesn't trigger any action.

Also, simply hovering the mouse sets aria-pressed to true, which seems to be an incorrect WAI-ARIA pattern!

Great catch! Both issues have been addressed.

Changes:

• Replaced Button / RadioCard with div[role="option"] inside a div[role="listbox"] pattern
• Removed aria-pressed entirely — selection state is now expressed via aria-selected
• Added click-to-toggle selection behavior
• Implemented keyboard navigation (Arrow keys, Enter/Space, Escape)
• Both hover and focus-visible now provide the same highlight feedback

Since this component's interaction is "browse + select" rather than "form input", the WAI-ARIA Listbox pattern is a better semantic fit.

• useHighlightTracking is a hook that retrieves the part currently to be highlighted within the iframe and continuously calculates the position and visibility of that element
to ensure the overlay is drawn in the correct location.

useComponentExplorerController is a hook that bundles the part selection state and iframe preview state from the parent component,
coordinating the entire behaviour of the component explorer, including communication with the iframe.

I noticed that the MutationObserver here calls scheduleFindAndHighlight upon DOM changes. However, scheduleFindAndHighlight returns calculated rects, which are then injected back into the style attributes in highlight-overlay.tsx. This effectively triggers another DOM change.

It seems we've hit an infinite loop: the observer detects a change, modifies the DOM, and then detects its own modification. While it’s limited to the iframe’s document.body, this continuous loop will definitely cause runtime overhead. Also, the infinite logs in React DevTools seem to be a direct symptom of this loop. What are your thoughts on whether we should optimize this?

It seems the error case you reported occurred prior to the documentation site update. This is because the explorer component was not added to the breadcrumb in this branch.

However, I completely agree with your concerns regarding the potential performance issue with MutationObserver. As you mentioned, there is a cycle where findAndHighlight calculates the rects and injects the styles, which triggers a DOM mutation, causing the MutationObserver to detect it again.

Currently, when the highlight part changes, the logic updates according to the flow below:

 findAndHighlight() ──── Calculate rect → setState → Re-render
 │ │
 │ DOM mutation occurs
 │ │
 │ MutationObserver detects
 │ │
 │ scheduleFindAndHighlight()
 │ │
 │ Reserve next frame via rAF
 │ │
 ▼ ▼
 Register ResizeObserver Re-execute findAndHighlight()
 │
 Compare rects ── Identical → Terminate ✅
 │
 Changed → setState → Repeat
 (Terminates after layout stabilizes)

As illustrated above, two defensive mechanisms have been applied to handle this:

1. rAF Debouncing

• scheduleFindAndHighlight schedules the execution for the next frame using requestAnimationFrame and cancels any previously registered callbacks. Therefore, even if the MutationObserver is triggered multiple times within the same frame, the actual execution is limited to a maximum of once per frame.

2. Cycle Termination via Rect Value Comparison (Newly Added)

• Inside findAndHighlight, we compare the previous rect values with the new rect values, and if there are no changes, we do an early return. Once the DOM stabilizes, the rect values become identical, preventing setState from being called. This naturally terminates the cycle of re-render → DOM mutation → MutationObserver re-trigger.

Additionally, the reason we set the MutationObserver target to document.body is because portal elements are rendered under the body. To properly detect changes in these portal elements, observation must be done at the body level.