-
Notifications
You must be signed in to change notification settings - Fork 683
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
Improved Image API #1956
Improved Image API #1956
Conversation
|
@supernova-at there are prettier fails. Check on that once. I am not sure how did it miss the git commit hook when you pushed them. |
if (propResourceWidth) { | ||
return propResourceWidth; | ||
if (!widths) { | ||
return undefined; |
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 this not be any default value returned if widths is not provided?
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.
It is odd that this would be undefined
. I would assume that the components that care about this require it, right? We definitely don't want resourceImage
throwing when it attempts to get widths[index]
here.
Maybe instead of having the useImage
talon do this work you could just pass the widths
array to the components that use it and have them do this work. We're already talking about potentially splitting them anyways so that components can directly import resource or simple image rather than 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.
This is a little shortcut if the caller doesn't pass a width
but does pass widths
.
If they don't pass either one, we literally don't have any information to go off of - undefined
seemed the best choice here. This will result in the img
element rendered to the DOM to not have a width
attribute and the network request to fetch this image won't include resize parameters.
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 realized it wasn't preferring the passed-in width
so I updated that in 4e798f7.
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.
Renaming is good 👍 for that.
However, I don't think an array is the right structure for maintaining the links between widths and breakpoints. I think a map fits this use case perfectly and would really simplify the logic in the sizes
memo in useResourceImage
.
const sizes = new Map();
sizes.set('default', 150)
sizes.set(100, 150);
sizes.set(200, 250);
const widths = [];
for (const [breakpoint, size] of sizes) {
if (breakpoint !== 'default') {
widths.push(`(max-width: ${breakpoint}px) ${size}px`);
}
}
widths.push(`${sizes.get('default')}px`)
console.log(widths.join(', '))
// (max-width: 100px) 150px, (max-width: 200px) 250px, 150px
Good suggestion. 👍 |
On it! 🖖 |
PR updated with new I named the prop |
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 changes. 👍
@@ -5,16 +5,12 @@ import { useCallback, useMemo, useState } from 'react'; | |||
* | |||
* @param {function} props.onError callback for error of loading image | |||
* @param {function} props.onLoad callback for load of image | |||
* @param {Map} props.resourceSizes image sizes used by the browser to select the image source. Supported keys are 'small', 'medium', and 'large'. | |||
* @param {number} props.resourceWidth the intrinsic width of the image & the width to request for the fallback image for browsers that don't support srcset / sizes. | |||
* @param {string} props.unconstrainedSizeKey the key in props.widths for the unconstrained / default width. |
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 is pretty weird. Is there a reason why we can't just let "default"
be the key here?
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.
It is always "default", I just didn't want every file to have to know that.
I agree it is weird though. I'm not married to the idea.
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.
The other way I thought of doing it was import
ing the key but then I ran into circular dependencies and Peregrine talons needing to import
Venia UI files.
Maybe it could live on the useImage
talon, I'll try that on for size.
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.
Yep, way better: 14fca61.
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.
The other way I thought of doing it was
import
ing the key but then I ran into circular dependencies and Peregrine talons needing toimport
Venia UI files.
Right, the dependency should flow in one direction; we shouldn't have any situations where peregrine
imports from venia-ui
.
…pwa-studio into supernova/90_improved_image_api
PR Updated:
|
Excellent. 💯 |
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.
Approved from my end. Will wait for @sirugh to approve as well.
Description
This PR improves the
Image
component API. Specifically, it:resourceSizes
/resourceSizeBreakpoints
towidths
and makes it aMap
resourceWidth
in favor ofwidth
(or the default entry inwidths
, if not present)resourceHeight
in favor ofheight
Related Issue
Closes JIRA-90.
Acceptance
Verification Stakeholders
@zetlen @jimbo
Specification
Verification Steps
📝 This is just a code refactor. There should be no impact on the UI.
Screenshots / Screen Captures (if appropriate)
Checklist