-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix <Image/>
's lazyRoot
and other optimizations
#37447
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
7584b12
to
4416195
Compare
This comment was marked as outdated.
This comment was marked as outdated.
4416195
to
031166c
Compare
useEffect(() => { | ||
if (unobserve.current) { | ||
unobserve.current() | ||
unobserve.current = undefined | ||
} | ||
|
||
if (el && el.tagName) { | ||
unobserve.current = observe( | ||
el, | ||
(isVisible) => isVisible && setVisible(isVisible), | ||
{ root, rootMargin } | ||
) | ||
} | ||
}, | ||
[isDisabled, root, rootMargin, visible] | ||
) | ||
if (isDisabled || visible) return | ||
|
||
const el = elementRef.current | ||
if (el && el.tagName) { | ||
unobserve.current = observe( | ||
el, | ||
(isVisible) => isVisible && setVisible(isVisible), | ||
{ root: rootRef?.current, rootMargin } | ||
) | ||
} | ||
}, [isDisabled, rootMargin, rootRef, visible]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before the PR
setIntersection
is used in<Image />
's callback ref, which will be called when<Image />
is first mounted.- During
setIntersection
, an IntersectionObserver instance is created and it observes theHTMLImageElement
withrootRef.current
is stillnull
- By the time
<Image />
is mounted, its parent element (lazyRoot
) hasn't been mounted yet, solazyRoot
has a value of{ current: null }
. - By the time the
setRoot
effect is committed, an IntersectionObserver instance is already created, and thelazyRoot
is never applied to the IntersectionObserver instance
After the PR
setIntersection
is used in<Image />
's callback ref, which will be called when<Image />
is first mounted.- During
setIntersection
, theHTMLImageElement
is synced to a ref (use ref instead of state to prevent extra re-rendering) - By the time
useEffect
commits the effect,lazyRoot
is already mounted, and theelementRef.current
also exists (it is set during<Image />
mounting) - Only then (during the effect) the observer is created with
lazyRoot
applied.
In short: The IntersectionObserver
is a web API (DOM API) and should be considered as a side-effect. A side-effect shouldn't be executed inside DOM's callback ref.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding a test for lazyRoot
?
<Image/>
& <Link/>
re-renders and other optimizations<Image/>
's lazyRoot
and other optimizations
4d1efed
to
8b95254
Compare
8b95254
to
f2df42b
Compare
test/integration/image-component/basic/pages/missing-observer.js
Outdated
Show resolved
Hide resolved
7367e0d
to
b90dd29
Compare
b90dd29
to
36e7ed7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a test to verify that this fixes the extra re-renders?
Hello again! It's been some time since the #33933 PR. What I am sure about is that it worked as intended and that the test was proving correctly the functionality. As far as I have understood this issue has to do with performance/ re-rendering, correct me If I am wrong. If you need anything specific please mention me since these days I have little to no time spending reviewing and testing everything again, but I am willing if it's urgent. Finally, according to my experience I want to tell that trying to correct React's too many renders, often leads to worse overall performance and that great attention must be payed to that kind of fixes. That means that often it's better to leave React do it's job even with more re-renders. Tools like react devtools in chrome can show accurately in milliseconds how much each react's commit costs. However I want to assure that I had not thoroughly tested my pr in terms of performance and that it's more than likely that it needs (heavy) optimization. Thank you |
I am wondering if it is possible to test against the rendering counts of a component with the existing test suite. Do Next.js integration test cases have some existing examples?
Yeah, your PR is sound and working as intended. This PR just also removes some redundant code introduced from your PR. |
Here's an example test:
and the corresponding test fixture (its just a page):
Although its probably best to use a global variable |
Thanks! But that test is based on I have found a testing library react-performance-testing, but it would patch the React in order to get rendering counts (which I am afraid is an anti-pattern, since React internal API might / would change from time to time). |
…/next.js into use-intersection-optimize
test/integration/image-component/no-intersection-observer-fallback/pages/_document.js
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
Also how about a test with a global variable let count = 0
just to verify the number of renders?
cc @ijjk @timneutkens for additional review here since this code is critical to all Next.js apps
}, []) | ||
|
||
const setRef = useCallback((el: T | null) => { | ||
elementRef.current = el |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to store the element reference in a useState()
since when setRef
is called we update the reference here but we aren't re-calling the useEffect
above so we won't observe the new ref unless the parent component re-renders?
Or are we changing this hook to have the assumption that the ref passed to setRef
should always only change when the parent re-renders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to store the element reference in a
useState()
since whensetRef
is called we update the reference here but we aren't re-calling theuseEffect
above so we won't observe the new ref unless the parent component re-renders?Or are we changing this hook to have the assumption that the ref passed to setRef should always only change when the parent re-renders?
Here is what I thought. setRef
here is only supposed to be called after component mounts. In <Image />
and <Link />
case, it is called inside the callback ref.
And the assumption here is that the DOM node itself would remain the same after the component mounts and before unmounts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading the React documentation again, updating a state inside a callback ref might not be a bad idea after all: How can I measure a DOM node? - Hooks FAQ.
I will change it to store the element reference in a state instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a test to count renders? #37447 (review)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a test to count renders? #37447 (review)
@styfle I still have no idea how to test this. It is almost impossible to test against component update counts.
One way is to patch the React reconciler through SECRET_INTERNAL_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
.
Another way is to add a global variable but it will have to live inside the next/image
component, introducing completely useless bytes in the production. The global variable just can't live inside the test case, because when a component re-renders, its parent components will not always re-render.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about globalThis._testRenderCount
so that its global and doesnt live inside a component and therefor outside of React's jurisdiction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about
globalThis._testRenderCount
so that its global and doesnt live inside a component and therefor outside of React's jurisdiction
globalThis._testRenderCount
does live outside of React, but the modification of this variable has to live inside the next/image
component (and probably has to be inside a useEffect
), which is what I am really concerned about.
As I said before, when a component re-renders, its parent components will not always re-render, thus we can't add the globalThis._testRenderCount
modification in <Image />
's parent component (it can't reflect how many times the child component has been updated).
The PR fixes
<Image />
and<Link />
components' extra re-renders,lazyRoot
has no effect, and applies some other optimizations.