-
Notifications
You must be signed in to change notification settings - Fork 31
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
refactor(Card): extract image #6066
Conversation
Settle on a single image type to avoid parallel branches that are harder to reason about. Allow optional parameters not to be set
Size Change: -578 kB (-26%) 🎉 Total Size: 1.68 MB
ℹ️ View Unchanged
|
⚡️ Lighthouse report for the changes in this PRLighthouse tested 2 URLs Report for Article
Report for Front
|
imageUrl?: string; | ||
avatarUrl?: string; | ||
}): { type: CardImageType; src: string } | undefined => { | ||
if (avatarUrl) return { type: 'avatar', src: avatarUrl }; |
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.
This logic looks to be wrong? The previous lines:
if (imageUrl && avatarUrl) {
imageType = 'avatar';
}
So this should be
if (avatarUrl && imageUrl) return { type: 'avatar', src: avatarUrl };
That said I don't think I fully understand why this logic is the way it is
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.
I could not figure it out either, and this causes no visual difference, so tempted to simplify it like so.
If we want to capture a missing imageUrl
and a set avatarUrl
, we should have a story against it.
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.
I agree the previous logic is a bit weird and I prefer the new version. I'll leave this up to the two of you. On my side, I'm happy with this PR so I have approved.
imagePosition: ImagePositionType, | ||
imagePositionOnMobile: ImagePositionType, | ||
imagePosition?: ImagePositionType, | ||
imagePositionOnMobile?: ImagePositionType, |
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.
Not sure I understand why these two are changing to optional. In the Props
types they remain non-optional: https://github.com/guardian/dotcom-rendering/blob/main/dotcom-rendering/src/web/components/Card/components/CardLayout.tsx#L7-L8
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.
You are right, I have now fixed this in b27392f
Co-authored-by: Max Duval <max.duval@guardian.co.uk>
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!
What does this change?
Settle on a single image value to avoid parallel branches that are harder to reason about.
Allow optional parameters not to be set.
Why?
I was looking at this code, and this seemed like a worthwile refactor.
This reduces the amount HTML on Cards without an image, including the
img
tag without asrc
attribute.Screenshots
No change, as can be glanced by the absence of Chromatic diffs.