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

report: add pwa-category-renderer #6486

Merged
merged 6 commits into from
Nov 7, 2018
Merged

report: add pwa-category-renderer #6486

merged 6 commits into from
Nov 7, 2018

Conversation

brendankenny
Copy link
Member

@brendankenny brendankenny commented Nov 6, 2018

part of #6395

screen shot 2018-11-06 at 11 38 58

adds the basic renderer for the revamped PWA section, with first icons and no longer collapsing behind passing, etc. Right now there are just the grayed out icons for each group (they don't fill in as the score increases).

@brendankenny
Copy link
Member Author

@hwikyounglee fixed the icon sizing

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

LGTM % nits!

all pretty straight forward stuff, thanks for breaking it up into this first step!


const auditRefs = category.auditRefs;

// Regular audits aren't split up into clumps, they're all top-level grouped.
Copy link
Collaborator

Choose a reason for hiding this comment

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

now I'm confused about the difference between a clump and group 😆

isn't the highest level collection called a clump now? as in this would be the unexpandable clump of audits?

oh wait I think I get it, maybe add into pass/fail/not-applicable clumps as a reminder for ppl like me? :)

Copy link
Member Author

Choose a reason for hiding this comment

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

maybe add into pass/fail/not-applicable clumps

good idea

const auditsElem = this.renderUnexpandableClump(regularAuditRefs, groupDefinitions);
categoryElem.appendChild(auditsElem);

// Manual audits are still clumped.
Copy link
Collaborator

Choose a reason for hiding this comment

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

so overall we have two clumps, regular and manual...right?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, that's confusing. I was thinking of it in terms of there's all the unclumped audits, then the clumped ones (just manual for this time), but it's literally renderUnexpandableClump, so it's just confusing to say they aren't clumped. I'll try to tweak

Copy link
Member Author

@brendankenny brendankenny Nov 6, 2018

Choose a reason for hiding this comment

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

to add to this confusion, it's renderUnexpandableClump, but we don't add a lh-clump class. We might just need another name for the div holding them (or no name, the same way we don't have a name for any audits that aren't grouped. They're just...there).

const perfCategoryRenderer = new PerformanceCategoryRenderer(this._dom, detailsRenderer);
perfCategoryRenderer.setTemplateContext(this._templateContext);

/** @type {Record<string, CategoryRenderer>} */
Copy link
Collaborator

Choose a reason for hiding this comment

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

hm we should probably gather a type up for our standard category ids soon huh?

Copy link
Member Author

Choose a reason for hiding this comment

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

hm we should probably gather a type up for our standard category ids soon huh?

yeah, it's hard to know where the boundary should be (the classic question of how much should the config define), but since we were going to hardcode them anyways, this seemed ok for now :) But agreed if we are going to do that, we should just be honest about it

@@ -92,6 +93,10 @@

--search-icon-url: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><path d="M31 28h-1.59l-.55-.55C30.82 25.18 32 22.23 32 19c0-7.18-5.82-13-13-13S6 11.82 6 19s5.82 13 13 13c3.23 0 6.18-1.18 8.45-3.13l.55.55V31l10 9.98L40.98 38 31 28zm-12 0a9 9 0 1 1 .001-18.001A9 9 0 0 1 19 28z" fill="%235E6268"/><path d="M0 0h48v48H0z" fill="none" /></svg>');
--remove-circle-icon-url: url('data:image/svg+xml;utf8,<svg height="24" width="24" xmlns="http://www.w3.org/2000/svg"><path d="M0 0h24v24H0z" fill="none"/><path d="M7 11v2h10v-2H7zm5-9C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm0 18c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8z" fill="%235E6268"/></svg>');

--pwa-fast-reliable-gray-url: url('data:image/svg+xml;utf8,<svg width="24" height="24" xmlns="http://www.w3.org/2000/svg"><g fill="none" fill-rule="nonzero"><circle fill="#DAE0E3" cx="12" cy="12" r="12"/><path d="M12.3 4l6.3 2.8V11c0 3.88-2.69 7.52-6.3 8.4C8.69 18.52 6 14.89 6 11V6.8L12.3 4zm-.56 12.88l3.3-5.79.04-.08c.05-.1.01-.29-.26-.29h-1.96l.56-3.92h-.56L9.6 12.52c0 .03.07-.12-.03.07-.11.2-.12.37.2.37h1.97l-.56 3.92h.56z" fill="#FFF"/></g></svg>');
Copy link
Collaborator

Choose a reason for hiding this comment

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

I always forget this, but the width="24" height="24" in there is just for relative sizing of itself and our external sizes can scale it without changing the string, right? i.e. it's just a coincidence that the background size of 24px happens to match this right now

(I know we're going to change this URL once it's colored and all that just checking)

Copy link
Member Author

Choose a reason for hiding this comment

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

So, it looks like the width="24" height="24" does nothing without a viewBox, which svgomg deleted for us. As long as we're happy keeping things at 24px we're good, but if we want to scale up we'll need a viewBox to define the internal coordinate system (which e.g. the <circle fill="#DAE0E3" cx="12" cy="12" r="12"/ is relative to) and then use width and height to control what viewBox is scaled up to.

(although since it's in a background-image, maybe background-size overrides width/height? Or they can be omitted and we can just use background-size? don't know)

@@ -645,7 +666,10 @@ details, summary {
.lh-clump > .lh-audit-group__description,
.lh-audit-group--diagnostics .lh-audit-group__description,
.lh-audit-group--opportunities .lh-audit-group__description,
.lh-audit-group--metrics .lh-audit-group__description {
.lh-audit-group--metrics .lh-audit-group__description,
.lh-audit-group--pwa-fast-reliable .lh-audit-group__description,
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is getting dicey, maybe we should think about an overall --decorated class or something

Copy link
Member Author

Choose a reason for hiding this comment

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

this is getting dicey

yeah, agreed. Ideally we can get clumps off of group classes, then we'd just need to update the perf renderer

});

afterAll(() => {
global.URL = undefined;
Copy link
Collaborator

Choose a reason for hiding this comment

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

FWIW, I'm not so sure we need to care about this now with jest

Copy link
Member Author

Choose a reason for hiding this comment

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

FWIW, I'm not so sure we need to care about this now with jest

won't we run into issues with --runInBand/-i?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we've had this in a comment discussion before 😆

AFAIK and have tested, the require/global sandbox is 100% unrelated to whatever processes it decides to run it in

Copy link
Member Author

Choose a reason for hiding this comment

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

I think we've had this in a comment discussion before 😆

ha, yes. We should actually verify :)

@@ -43,6 +44,11 @@ describe('ReportRenderer', () => {
require('../../../../report/html/renderer/performance-category-renderer.js');
}
global.PerformanceCategoryRenderer = PerformanceCategoryRenderer;
if (!PwaCategoryRenderer) {
PwaCategoryRenderer =
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm so confused why we needed to do this for PerformanceCategoryRenderer did you run into something or was it just straight copy?

Copy link
Member Author

Choose a reason for hiding this comment

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

did you run into something or was it just straight copy?

total copy/paste job. I'll check it out

Copy link
Member Author

Choose a reason for hiding this comment

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

ah, so the issue is that we require PerformanceCategoryRenderer (same with PwaCategoryRenderer), but it extends CategoryRenderer, assuming CategoryRenderer is a global (as it will be when viewing the report in the browser). So if it's required at the beginning of the test file, it immediately errors since the class declaration is run immediately (other things, like accessing the global URL, aren't run until a method is actually called).

So I think the solution is either something like this, or we wrap the class declaration in something else (which seems worse). Maybe we can come up with a cleaner version of this dance?

Copy link
Collaborator

Choose a reason for hiding this comment

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

well I meant more why there's this weird if and it gets stored in a local instead of getting attached straight to global :) but gotcha 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

well I meant more why there's this weird if and it gets stored in a local instead of getting attached straight to global

ah, I see now. Yeah. I'll fix in the next PR when I add more tests

Copy link
Member

@exterkamp exterkamp left a comment

Choose a reason for hiding this comment

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

Love the new look!!! 🎉

Ultra nit: When clicking a row the icons overlap the 1px blue border.
image

lighthouse-core/report/html/report-styles.css Outdated Show resolved Hide resolved
@brendankenny
Copy link
Member Author

I feel like a fill of #ffffff is too low contrast

Maybe we can move to a comment in #6395 (or an offshoot issue)?

@brendankenny
Copy link
Member Author

Ultra nit: When clicking a row the icons overlap the 1px blue border.

good catch. Normally a group description provides margin space between the group title and the audit results, but the PWA groups have no description. I added a bottom margin to group titles, which fixes the PWA section and collapses when paired with a description, leaving most of the rest of the report unchanged.

It does leave the Metrics title way too high over the metric audits, though, so I overrode the margin just for that one group in the performance section (which seems reasonable, since there's a few lines in the same place entirely devoted to shrinking whitespace in just the metrics group)

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.

3 participants