Skip to content
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

Merged
merged 6 commits into from
Mar 2, 2018

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented Jan 29, 2018

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?

Copy link
Member

@paulirish paulirish left a 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) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bytesDetails

Copy link
Collaborator Author

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);
Copy link
Member

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.

Copy link
Collaborator Author

@patrickhulce patrickhulce Jan 30, 2018

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?

@patrickhulce
Copy link
Collaborator Author

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.

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

@googlebot
Copy link

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 cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@paulirish
Copy link
Member

paulirish commented Feb 14, 2018

Remaining audits that need to be adapted:

'link-blocking-first-paint', 'script-blocking-first-paint', 'time-to-first-byte', 'redirects',

@patrickhulce patrickhulce changed the title WIP: (╯°□°)╯︵┻━┻ the strings core: improved consumption of audit.details Feb 15, 2018
@patrickhulce patrickhulce force-pushed the (╯°□°)╯︵┻━┻_the_strings branch from a23a010 to b08335f Compare February 23, 2018 17:39
@paulirish
Copy link
Member

paulirish commented Feb 23, 2018

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:
tinyhouse.json.txt

@paulirish
Copy link
Member

This is LGTM.
When we land, we'll have officially kicked off the 3.0 on master.

@paulirish paulirish added the 3.0 label Mar 2, 2018
@paulirish paulirish merged commit 1a620b8 into master Mar 2, 2018
@paulirish
Copy link
Member

Hello 3️⃣ ⚫️ 0️⃣ !

@paulirish paulirish deleted the (╯°□°)╯︵┻━┻_the_strings branch July 2, 2018 19:07
@paulirish paulirish removed the 3.0 label Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants