-
Notifications
You must be signed in to change notification settings - Fork 821
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
[Avatar] Fix flashing when image is already cached #3008
base: main
Are you sure you want to change the base?
[Avatar] Fix flashing when image is already cached #3008
Conversation
Awesome, I've been waiting for this I was actually about to hack my own Avatar together myself... Will this be useable directly into Shadcn and NextUI or will we need an update from NextUI directly? |
@LeakedDave the same avatar flicker issue in shadcn/ui should be fixed just by bumping the radix version if this fix is released. For nextui I think the same idea can be implemented to this hook: https://github.com/nextui-org/nextui/blob/canary/packages/hooks/use-image/src/index.ts |
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.
One minor change and I'll merge 👍
packages/react/avatar/src/Avatar.tsx
Outdated
@@ -116,35 +119,47 @@ AvatarFallback.displayName = FALLBACK_NAME; | |||
|
|||
/* -----------------------------------------------------------------------------------------------*/ | |||
|
|||
function setImageSrcAndGetInitialState(image: HTMLImageElement, src?: string): ImageLoadingStatus { |
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 we rename this to resolveLoadingStatus
?
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.
@chaance done! I also rebased with main since there's some conflict with the referrerPolicy change
dc693e7
to
308d236
Compare
packages/react/avatar/src/Avatar.tsx
Outdated
function useImageLoadingStatus(src?: string, referrerPolicy?: React.HTMLAttributeReferrerPolicy) { | ||
const [loadingStatus, setLoadingStatus] = React.useState<ImageLoadingStatus>('idle'); | ||
const image = React.useRef(new window.Image()); |
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.
Sorry, one more thing I noticed. This will error in SSR. We want to ensure that hydration is complete before initializing the image.
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.
Here's my suggested fix:
- Check if the app is hydrated on the client (this can either be a new function in the utils package or included in this file for now)
- If the app is not hydrated (SSR + first client render) initialize the image ref as
null
- Initialize the state as "loading" pre-hydration to prevent client/server mismatch
function resolveLoadingStatus(image: HTMLImageElement | null, src?: string): ImageLoadingStatus {
if (!src) {
return 'error';
}
if (!image) {
// image is not initialized during SSR. Ensures the initial state is
// 'loading' on both the server and the client to prevent hydration errors.
return 'loading';
}
if (image.src !== src) {
image.src = src;
}
return image.complete && image.naturalWidth > 0 ? 'loaded' : 'loading';
}
function useImageLoadingStatus(src?: string, referrerPolicy?: React.HTMLAttributeReferrerPolicy) {
const isHydrated = useIsHydrated();
const image = React.useRef<HTMLImageElement | null>(isHydrated ? new window.Image() : null);
const [loadingStatus, setLoadingStatus] = React.useState<ImageLoadingStatus>(() =>
resolveLoadingStatus(image.current, src)
);
useLayoutEffect(() => {
setLoadingStatus(resolveLoadingStatus(image.current, src));
}, [src]);
useLayoutEffect(() => {
// We can safely assume that image.current is not null because hydration is
// complete by the time this effect runs
const img = image.current!;
const updateStatus = (status: ImageLoadingStatus) => () => {
setLoadingStatus(status);
};
const handleLoad = updateStatus('loaded');
const handleError = updateStatus('error');
img.addEventListener('load', handleLoad);
img.addEventListener('error', handleError);
if (referrerPolicy) {
img.referrerPolicy = referrerPolicy;
}
return () => {
img.removeEventListener('load', handleLoad);
img.removeEventListener('error', handleError);
};
}, [referrerPolicy]);
return loadingStatus;
}
function subscribe() {
return () => {};
}
function useIsHydrated() {
return React.useSyncExternalStore(
subscribe,
() => true,
() => false
);
}
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.
Good catch! also TIL useSyncExternalStore is the recommended way to detect hydration. I'll make the change
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.
@chaance done, I added a test for SSR and make sure it works in the ssr-testing app too. Need to make some change from your suggestion but overall it works. One thing is that the SSR testing will log this error:
Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes.
since we use useLayoutEffect for Avatar. It's just a warning from jest though, and the Avatar component server rendered to its fallback component just fine as tested with unit test and manually checked in the ssr-testing app
Hey @chaance @rkkautsar, is this PR ready to be merged? 🙏 |
Hello, I just want to follow if this PR is ready? |
@mackermans @quachthientai need maintainer to review the change 😅 |
Please do not leave comments like "bump" and "+1", they are unhelpful. At the moment this project is just me, and I've got a large backlog of issues and need to prioritize accordingly. |
@rkkautsar do you see an opportunity to finish this PR with the last PR comment? |
Co-authored-by: Chance Strickland <[email protected]>
@chaance sorry just got the chance to work on this again. I applied your suggestion and tested that everything still works. |
Description
Fixes #2044 by initializing loadingStatus with
loaded
if theimage.complete
is true, based on @lauri865 suggestion in the linked issue.Based on MDN,
image.complete
will be true if:I added test case for all the cases, although I imagine the last case might be different from browser to browser. In Chrome, when image loading is disabled the load event will never fire and
image.complete
will always be false. To be safe I added another check forimage.naturalWidth > 0
since image with no data will have naturalWidth = 0.I also added test and story for the case when image src changing to make sure my change can handle the changing src.
Tests added:
✓ does not leak event listeners (7 ms)
✓ can handle changing src (627 ms)
✓ should render the image immediately after it is cached (327 ms)
✓ should not render image with no src (5 ms)
✓ should not render image with empty string as src (3 ms)
✓ should show fallback if image has no data (4 ms)
Storybook added: