-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
core(font-size): remove deprecated DOM.getFlattenedDocument #11248
Merged
Merged
Changes from 3 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 we've ever used generator syntax in Lighthouse outside of the very unusual asset saver case which is very specific to allowing streamable results, probably deserves some sort of comment or justification :)
is there an actual benefit here compared to just doing a filtered map instead? AFAICT, we're just using the iterator to push all of these objects onto an array anyway, but maybe there were other memory pressure reasons I'm mising?
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.
(and really is a product of the Node < 8.10 days when we couldn't have strings over 256MiB (#1685 (comment)) and no one has touched that save method for three years)
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.
Happy to change, not a sticking point, but I don't like the idea of avoiding entire language features because they are new or not commonly used :) Would a comment linking to "how generators work" help? Is the main concern just that someone doesn't know what
*
is, or that even if they do, do you think generators are hard to reason about?I appreciate a generator here as the size of the data created is not bounded. It scales with the number of elements on the page, and with the amount of text within those elements. Since only a single value needs to be processed at a time, and because the creation of said value is rather complex, extracting as a generator function made sense to me.
The alternative seems to be:
textLength
instead of thetext
. Here I reverted that, as it's a derived property better calculated by the calling code.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.
Mostly this. I wouldn't expect most developers to immediately understand how this function works compared to adding items to an array. For this reason, I would only really use a generator in a shared codebase when the benefits are significant (like in the string creation case of asset saver) which is accompanied by that justification in comments.
Ah, OK I didn't notice this. If we held on to
text
for any significant part of the filtering step I might agree with you this is sufficient justification, but much like your other simplifications in this PR, we could solve it by limiting the returned information and just changetext
to atextLength: getTextLength(text)
invocation into the iterator function, right?I'm not sure I follow this one, we'd still be calculating it with the exact same method now, we'd just compute it before returning the node object.
Final thoughts:
I understand your concern about refusing to adopt new language features and ending up with a ES20XX-era codebase forever. I'm not as worried about this being the case as we've extensively adopted several features newer to node than generators, it's primarily that generators are rarer in applicability for Lighthouse (and therefore in my belief less likely to be easy to read for the average developer) than asynchronous code.
While my primary concern was wrong to lean exclusively on "it's different, so no", there is still some merit to consistency in patterns. @paulirish mostly converted me here on avoiding
reduce
in pretty much every situation I would've used it previously for easier reading to those less accustomed toreduce
as a general-purposefor
-loop, and I believe in other recent reviews of new contributors we both concurred on use of afor...of
instead of a long.filter().map().filter().forEach()
chain. Not that there's never a time to use those new patterns, but for a situation in which the dominant pattern already fits well and the new pattern is sufficiently different in complexity of comprehension, I'd prefer the former.