-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
feat: add prefetch="viewport"
support to <Link>
#6433
Conversation
Signed-off-by: Logan McAnsh <logan@mcan.sh>
Signed-off-by: Logan McAnsh <logan@mcan.sh>
🦋 Changeset detectedLatest commit: 748d6a0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Signed-off-by: Logan McAnsh <logan@mcan.sh>
c979409
to
ba6a81e
Compare
prefetch="viewport"
support to <Link>
b292eac
to
3fd52d2
Compare
Signed-off-by: Logan McAnsh <logan@mcan.sh>
let callback: IntersectionObserverCallback = (entries) => { | ||
entries.forEach((entry) => { | ||
setShouldPrefetch(entry.isIntersecting); | ||
}); | ||
}; |
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.
Should the observer be disconnected after prefetch is set? That way the IntersectionObserver doesn't need to keep observing if ref.current
is in the viewport
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.
mostly depends on if we should clean up link preloads when the link leaves the viewport. another thing would be that if it re-enters the vp, should it refetch the loader?
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.
Removing/re-adding link tags if an element scrolled out of and back into the viewport would be consistent with our prefetch="intent"
behavior
3e01f90
to
ee74d1b
Compare
{...props} | ||
{...prefetchHandlers} | ||
ref={mergeRefs(forwardedRef, 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.
Is there any internal react overhead in attaching a ref? This feels potentially troublesome since we now attach a ref
to every Link, even if the user didn't forward a ref and if they're not using prefetch="viewport"
. Does a page with hundreds of links get immediately "slower" with no way for the user to opt out of the refs?
I took a stab at an opt-in ref approach in 44f28f3
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.
There's no perf hit per @jacob-ebey so going to back out that commit
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.
Made a small change in 44f28f3 to only attach the ref
when prefetch="viewport"
is specified so we're not attaching a ton of refs if the viewport option is not used.
This reverts commit 44f28f3.
Think this should be good to go now. I'm OOO tomorrow but will see if Jacob can merge once CI passes |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Signed-off-by: Logan McAnsh logan@mcan.sh
Closes: https://canary.discord.com/channels/770287896669978684/940264701785423992/1109137291974279239
Testing Strategy: