-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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: improved consumption of audit.details #4384
The head ref may contain hidden characters: "(\u256F\u00B0\u25A1\u00B0\uFF09\u256F\uFE35\u253B\u2501\u253B_the_strings"
Conversation
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.
am kinda surprised we had no tests that asserted the details object. can you add some? alternatively we move those tests below to use details instead of extInfo.
const kbDisplay = this.bytesToKbString(bytes); | ||
const percentDisplay = Util.formatNumber(Math.round(percent)) + '%'; | ||
return `${kbDisplay} (${percentDisplay})`; | ||
static bytesToDetails(bytes) { |
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.
bytesDetails
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.
done
* @return {!Element} | ||
*/ | ||
_renderBytes(details) { | ||
let text = Util.formatNumber(details.value, details.granularity || 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.
seems like we should either be using Util.formatBytesToKB
or the nonexistent Util.formatBytes
, but just falling back to formatNumber
seems wrong to 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.
this should never even happen, so I don't have a strong opinion on how it's handled buuuuuuut... creating a new helper function that is never called does seem a bit silly, so I'm inclined to say we just always do formatBytesToKB and console.warn if display unit isn't kb?
that was because details is still fragile and annoying based on the fact that adding a new column would require rebasing all of our tests. IMO I still don't really see it as a wholesale replacement of extendedInfo in terms of ergonomics, if people rely on array indices to be stable they'll be more disappointed than just using extendedInfo maybe we should work out exactly how we expect people to consume this data and what we want to guarantee as stable? doesn't seem like we can guarantee the text of the headers to be the same and certainly not the index of the column, so extendedInfo-style might actually be a better bet |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
Remaining audits that need to be adapted:
|
a23a010
to
b08335f
Compare
Update: moved to #4616 Here's my initial take at merging extInfo and details together and using proper key names: http://bit.ly/2HDIk8q (lol the branch name hit a github bug. :) Also here's a LHR this branch produces: |
This is LGTM. |
Hello 3️⃣ ⚫️ 0️⃣ ! |
moves us toward #4614 (and #3115), really helps out using details data
@paulirish did you still want to tackle the rest or is this for me? :) either way should we bring the issue in to ocho and assign it?