-
Notifications
You must be signed in to change notification settings - Fork 64
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: integrate js-core into react-imgix #776
Conversation
Features
Styles
Tests
Bug Fixes
Code Refactoring
Performance Improvements
Build System
ContributorsCommit-Lint commandsYou can trigger Commit-Lint actions by commenting on this PR:
|
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.
LGTM 👍🏼
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.
Overall I think this is really great and reduces the complexity of this library. Nice work! 🎉
DPR_QUALITY
andDPR_QUALITY_VALUES
should be able to be removed fromconstants.js
because I think they're no longer used- I think the changes to use
{...object}
rather thanObject.assign
are nice stylistically, but they were introduced for performance reasons, and we shouldn't change these back unless we're sure that there is no change to performance. There was a 30% increase in performance and it would be a shame to lose these gains. Context: perf: remove object spreading #423 - The title should be updated to not include a "."
import extractQueryParams from "./extractQueryParams"; | ||
import { config } from "./common"; | ||
const PACKAGE_VERSION = require("../package.json").version; |
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.
Let's change this to using common/constants.js
, must have slipped through the cracks.
const [scheme, rest] = src.split("://"); | ||
const [domain, ...pathComponents] = rest.split("/"); |
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.
An improvement here, if you want, could be to use the built-in URL
interface to do this extraction. You know, cos, edge cases.
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.
Won't this add encoding to the path though? Or maybe I don't understand how I'd use the built-in interface?
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.
Yeah I think you're right
|
||
function compactParamKeys(longOptions, width, height) { |
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 don't think having width
and height
here as parameters is too coupled. I think it would be better to push this to the consumer with either:
const params = compactParamKeys({...longOptions, w: width, h: height});
or
const params = {...compactParamKeys(longOptions), w: width, h: height};
src/constructUrl.js
Outdated
return /^\d+(\.\d+)?:\d+(\.\d+)?$/.test(aspectRatio); | ||
} | ||
|
||
function buildChildProps(obj, src, attributeConfig, width, height, refType) { |
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 think this function relates more to the components where it is called, so at least it should be located in that file.
It seems like a bit of a smell to be passing this
around - seems like it could go wrong in the future if this function was to incorrectly assign to obj
. I wonder if it's better if it's possible to make this pure, or just to deal with this logic being duplicated in the separate components. It's not super complicated so I'm not sure how much benefit there is to extract it into a common function.
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.
Yeah, I think it smells a bit too, but I wanted to try to extract/distill some of the structure of what's going on here. I'll look into refactoring this.
const allParams = { ...params, ...imgixParams, dpr }; | ||
const srcOptions = { | ||
...params, | ||
fit: "crop", | ||
...imgixParams, | ||
...(disableLibraryParam ? {} : { ixlib: `react-${PACKAGE_VERSION}` }), | ||
...allParams, |
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 this the fix related to this comment?
Lastly, a temp fix was made for the Background component. Prior to this PR, the flow of the code/params caused duplicate param key-value pairs to be written into query strings.
} | ||
|
||
export default targetWidths(); | ||
export default ImgixClient.targetWidths(); |
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.
Haha, nice! 👏
expect(srcset.split(",\n")[0].split(" ")).toHaveLength(2); | ||
const aSrcFromSrcSet = srcset.split(",\n")[0].split(" ")[0]; | ||
expect(aSrcFromSrcSet).toContain(src); | ||
const aWidthFromSrcSet = srcset.split(", ")[0].split(" ")[1]; | ||
const aWidthFromSrcSet = srcset.split(",\n")[0].split(" ")[1]; |
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 probably little value testing this stuff in react-imgix anymore since it's now implemented and tested by @imgix/js-core
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. I wanted to at least demo "hey, this works kind of like it did before." I wonder what work I could do to distill down the test suite now.
Closing in favor of #780 |
The purpose of this PR is to integrate
@imgix/js-core
intoreact-imgix
. First,targetWidths
has been reimplemented in terms ofthe js-core client. Second,
buildSrc
has been implemented in terms ofImgixClient.buildSrcSet
. Lastly, a temp fix was made for theBackground
component. Prior to this PR, the flow of the code/paramscaused duplicate param key-value pairs to be written into query strings.
Ideally, we want to avoid getting into this kind of situation
altogether. However, doing that will require a bit more reworking,
refactoring, and (possibly || probably) breaking changes.
Closes #763