-
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
report: expand groups within Passed Audits #6930
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.
I'd prefer this, but I believe the conclusion was that there would be no groups under passed.
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.
so is the end result that groups are not collapsible anymore? they are always expanded?
// Expanded by default! | ||
// 1. The 'failed' clump has all groups expanded. | ||
// 2. If a clump is collapsed (passed, n/a), we want the groups within to already be expanded | ||
const auditGroupElem = this.renderAuditGroup(groupDef, {expandable: false}); |
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 is a little confusing, it's probably because I don't remember what our opts actually do at this point 😆 so expandable
means isExpansionToggleable
and it's expanded by default?
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.
agree it's a funny name. expandable
means collapsedAndCanBeExpanded
Hmm I dont remember that. but Ok. :) Here's a GIF showing (1) current master - two collapsed groups under Passed. then (2) this PR - two expanded groups under Passed. The gif doesn't show (C) current PSI - groups are intermingled under Passed. Brendan thought the conclusion was option C, but I forget, tbh. |
yes, I remember it clearly because I was sad to lose the headings under Passed (I believe the argument was that you don't really need them at that point, since they're just a list of passed audits), and I had just finished my sweet ascii art and didn't want to change it :) |
+1 to the idea of getting rid of both the description text and headers within passed audits/not applicable (i.e. how PSI currently handles it). Simple = good. The only addition I'd like to make is some link that is presented to the user upon expansion of the passed audit/not applicable categories that sends them to a canonical list of the audits with their respective categories, so that on the off chance that a user wants to map a passed audit to its category it is easy for them to do so. WDYT? |
Yah now that I've looked at it more, I support the idea of just dropping group titles/descriptions within these. its extra text that we don't really need for low-priority content. |
I'll update the PR with those changes. |
should #6279 be closed? |
There's no grouping within Passed, Not Applicable, Manual any longer. |
@@ -272,7 +274,7 @@ class CategoryRenderer { | |||
*/ | |||
renderUnexpandableClump(auditRefs, groupDefinitions) { |
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.
weren't you going to rename?
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.
weren't you going to rename?
oh, maybe because pwa-category-renderer.js
also uses it?
@@ -291,7 +293,8 @@ class CategoryRenderer { | |||
* ├── audit 5 | |||
* └── audit 6 | |||
* clump (e.g. 'manual') | |||
* ├── … | |||
* ├── audit 1 | |||
* ├── audit 2 | |||
* ⋮ |
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.
maybe
/**
* Renders a clump (a top level report section), under a status of failed, manual,
* passed, or notApplicable. The result ends up something like:
*
* failed clump
* ├── audit 1 (w/o group)
* ├── audit 2 (w/o group)
* ├── audit group
* | ├── audit 3
* | └── audit 4
* └── audit group
* ├── audit 5
* └── audit 6
* other clump (e.g. 'manual')
* ├── audit 1
* ├── audit 2
* ├── …
* ⋮
@@ -305,17 +308,15 @@ class CategoryRenderer { | |||
return failedElem; | |||
} | |||
|
|||
const expandable = true; | |||
const elements = this._renderGroupedAudits(auditRefs, groupDefinitions, {expandable}); | |||
|
|||
const clumpInfo = this._clumpDisplayInfo[clumpId]; | |||
// TODO: renderAuditGroup shouldn't be used to render a clump (since it *contains* audit groups). |
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 TODO makes no sense now. Maybe // TODO: renderAuditGroup shouldn't be used to render a clump since it's a clump, not a group.
clumpElem.classList.add('lh-clump', clumpInfo.className); | ||
|
||
elements.forEach(elem => clumpElem.appendChild(elem)); | ||
// For all non-failed clumps, we don't group |
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 might not make much sense outside the context of this PR. Just // Add all audit results to the clump.
(or add an intermediate const auditElems = auditRefs.map(...)
and can probably avoid the comment altogether)
proposal on top of this in #6982 |
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.
LGTMMM
This was the UX conclusion when PSI noticed the groupings in our new renderer.