-
Notifications
You must be signed in to change notification settings - Fork 132
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
Re-introduce lazy loading #2367 #2450
Re-introduce lazy loading #2367 #2450
Conversation
Add log warning for missing width and height
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2450 +/- ##
==========================================
+ Coverage 48.97% 49.04% +0.07%
==========================================
Files 124 124
Lines 5254 5262 +8
Branches 1112 1118 +6
==========================================
+ Hits 2573 2581 +8
Misses 2376 2376
Partials 305 305 ☔ View full report in Codecov by Sentry. |
Sure, I will work on it, thanks for the suggestion! |
@yucheng11122017 I have changed the warning message to only specify the file and not the code snippet. This is because I realised we can only get the code snippet if the However, I think it is sufficient to only show the file paths since the users can now have an idea on where to do the changes. |
I think having just the filepath but not the code is OK, but can you get the filepath to precede the warning message and be on the same line? Just think its weird that it prints "In ___" afterwards, it looks messy... |
@kaixin-hc thanks for the suggestion! I have modified the output as below, not sure if the use of What do you think? |
lgtm |
|
||
nodeProcessor.processNode(testNode, new Context(path.resolve(''), [], {}, {})); | ||
|
||
const logMessage = consoleSpy.mock.calls[0]; |
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 you can write an expect statement like expect(consoleSpy.warn).toHaveBeenCalledWith(undefined);
and combine these two
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.
Thanks for the suggestion!
I am thinking of another way to do it expect(consoleSpy).not.toHaveBeenCalled()
.
It checks if the warn
method is not being called at all
const testCode = '<pic scr="" alt="" width="300" lazy></pic>'; | ||
const testNode = parseHTML(testCode)[0] as MbNode; | ||
|
||
const consoleSpy = jest.spyOn(logger, 'warn'); |
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'm OK with this I think - though I remember some discussions about spy-on vs mock, where mock tends to be preferred over spying as errors can't be produced from winston.
Here is some additional discussions on stack overflow for your consideration...
And a related issue in markbind #2099 - feel free to weigh in with your thoughts.
Thanks @luminousleek for sharing these links with me!
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've got an example of how you might mock the logger in #2463
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.
Thank you for the suggestions @kaixin-hc @luminousleek ! Will follow the suggestions and update my code.
Co-authored-by: david <71922282+itsyme@users.noreply.github.com>
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.
Hi @LamJiuFong thanks for the work on this PR!
Personally, I'd prefer not to override the height to maintain the aspect ratio - this would be breaking behaviour in that case. Plus if users want to change the aspect ratio that is their choice as well.
In other words, I think the expected behavior should be: if users enter both height and width, that should be used. Only if either one is missing, do we maintain the height ratio.
wdyt? tagging @kaixin-hc as well
@@ -175,7 +175,6 @@ export class NodeProcessor { | |||
|
|||
// log warnings for conflicting attributes | |||
if (_.has(warnConflictingAtributesMap, node.name)) { warnConflictingAtributesMap[node.name](node); } | |||
|
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.
Please don't have unnecessary changes
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.
Ok, will make the changes!
const imgHeight = renderedImg.naturalHeight; | ||
const imgWidth = renderedImg.naturalWidth; | ||
const aspectRatio = imgWidth / imgHeight; | ||
if (this.hasWidth) { // if width is present, overwrite the height (if any) to maintain aspect ratio |
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.
Hmmm if this behavior necessary? I think its ok for a user to adjust the aspect ratio as needed.
This might also be breaking behavior in that case.
Also another thing discussed by @kaixin-hc and I is the behaviour when the width and height is relative eg. 50% or max-width. Could you check @LamJiuFong and see if lazy loading will cause issues in that case? |
default: | ||
break; | ||
} | ||
} catch (error) { | ||
logger.error(error); | ||
} | ||
|
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 the newlines were intentional for readability! Perhaps reverting them could prevent any unnecessary 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.
Ok, will make the changes!
@yucheng11122017 Thanks for raising them up, I have not thought about the issues you mentioned when I was solving this issue. Previously, I followed the user guide to enforce the aspect ratio According to https://stackoverflow.com/questions/65376615/set-height-of-image-with-100-width-for-cls-cumulative-layout-shift: it seems like layout shifts won't occur if the widths and heights are relative. Also, our current implementation of Thanks for commenting! |
Thanks for the detailed response @LamJiuFong
Ah I see I must have missed this. In that case, I think its ok to continue with this current implementation. We can discuss seperately if we should allow the overriding of aspect ratio in that case. Checking in with @kaixin-hc if you have other opinions?
Ok great!
Oh hmm I see. I was not aware of this. Thank you for investigating! We can discuss this seperately as well but you can ignore it for now. Thanks! |
Thanks for investigating! I'm good to shelve those questions for another issue and merge this first. (But um. Why the checks failing?) |
Thanks for the comments!
The logger was imported twice after I merged the master branch. I have fixed the issue. |
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! Thanks for the work
What is the purpose of this pull request?
Fix #2367
Overview of changes:
Add
lazy
property to<pic>
and<annotate>
Checks if either width or height are given when users want to use lazy loading, a warning will be logged to the console when both are missing
Anything you'd like to highlight/discuss:
Testing instructions:
Proposed commit message: (wrap lines at 72 characters)
Add
lazy
property to pic and annotateChecklist: ☑️
Reviewer checklist:
Indicate the SEMVER impact of the PR:
At the end of the review, please label the PR with the appropriate label:
r.Major
,r.Minor
,r.Patch
.Breaking change release note preparation (if applicable):