fix(useElementByPoint): avoid a re-render on every frame in multiple mode - #214
Merged
childrentime merged 1 commit intoJul 30, 2026
Conversation
…mode elementsFromPoint() allocates a new array on every call, so the rAF loop handed setElement a fresh reference each frame and re-rendered the consuming component roughly 60 times a second even while the pointer sat still. Compare the hit list by contents and keep the previous array when nothing under the point changed. The single-element branch needs no such check - elementFromPoint returns the same node and React bails out on its own. Adds the first tests for this hook, covering both that an unchanged hit list does not re-render and that a changed one still does.
Owner
|
Thanks @ostapondo! Killing a 60fps re-render loop while keeping the array identity stable is a real win for anyone memoizing on |
childrentime
added a commit
that referenced
this pull request
Jul 30, 2026
…eck gate #214 was written before the typecheck gate from #211 landed: `next` is `Element[] | Element | null`, and the `multiple &&` guard can't narrow it, so `next.length` / `next[i]` fail tsc. Guard with `Array.isArray(next)` instead — runtime-equivalent, since the single-element branch never produces an array — and type the spec's reassigned hit list as `Element[]`. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
childrentime
added a commit
that referenced
this pull request
Jul 31, 2026
Fixes - useOrientation: lockOrientation/unlockOrientation had inverted isBrowser guards — they early-returned in the browser and only ran during SSR, making both no-ops where they mattered. Closes #215. - useInterval: with controls: true, an interval started through resume() kept firing after unmount, and calling resume() twice leaked a timer neither pause() nor unmount could reach. Closes #212. - useMicrophone: level stayed frozen at the last reading after stop(); it now resets to 0. Closes #213. - useElementByPoint: multiple mode re-rendered on every rAF frame because elementsFromPoint allocates a fresh array; the hit list is now compared element-by-element and kept stable when unchanged. Closes #214. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
With
multiple: true,useElementByPointre-renders the consuming component onevery animation frame, even when the pointer hasn't moved and the elements under
it haven't changed.
elementsFromPoint()returns a freshly allocated array on each call, so the rAFloop hands
setElementa new reference every frame. React compares by identity,sees a change, and re-renders — roughly 60 times a second, for as long as the
hook is active. The single-element path doesn't have this problem, since
elementFromPoint()returns the same node and React bails out on its own.The fix compares the hit list by contents and keeps the previous array when
nothing changed. I used the functional form of
setElementso the comparisonsees the committed value without needing an extra ref.
Type of Change
Checklist
No doc change — public API and return values are unchanged.
This hook had no spec file, so I added one. Three tests: the element is reported
for the single case, an unchanged hit list no longer re-renders (3 renders over 3
frames on
main, 0 here), and a hit list that genuinely changes still updates —that last one matters, since a comparison like this is exactly the kind of change
that can silently freeze state.