-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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: subRow refactor, rename to subItem #10867
Conversation
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-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 by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
types/audit-details.d.ts
Outdated
@@ -116,7 +122,8 @@ declare global { | |||
|
|||
export interface TableItem { | |||
debugData?: DebugData; | |||
[p: string]: undefined | ItemValue | ItemValue[]; | |||
subRows?: TableSubRows; |
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.
Can we just call these subItems
at this point?
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.
Can we just call these subItems at this point?
👍 Makes sense to me, not sure if others were involved in the original bike shedding and will want to weigh in
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.
subRows => subItems
for the detail type, and subRows => subItemsHeading / subHeading
for the headings
object?
I think this refactor may have removed some of the hesitation in doing this before?
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.
you already know I'm onboard for subItems
;)
@googlebot I consent. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
'2191 +/- 50', | ||
'2182 +/- 50', | ||
'1259 +/- 50', | ||
subItems: [ |
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 an excellent improvement!
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.
some naming/slight rearranging suggestions but otherwise looking really good to me!
types/audit-details.d.ts
Outdated
|
||
// TODO: drop TableColumnHeading, rename OpportunityColumnHeading to TableColumnHeading and | ||
// use that for all table-like audit details. | ||
|
||
export interface TableColumnHeading { | ||
/** | ||
* The name of the property within items being described. | ||
* If null, subRows must be defined, and the first sub-row will be empty. | ||
* If null, subHeading must be defined, and the first sub-row will be empty. |
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.
wasn't this the comment that was confusing before? It's not that the first sub-row will be empty, it's...something else :)
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.
let's do subItem row
in this comment.
and sub-item-row
in css.
{url: 'https://www.example.com', sources: ['a', 'b', 'c']}, | ||
{ | ||
url: 'https://www.example.com', | ||
subItems: makeSubitems([ |
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.
nit: just making this a subitems
object is one line longer and doesn't take a trip through a function call :)
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'm trying to reduce object fatigue to increase test readability. The function is free and avoids an extra level of nesting, which for these details
objects can be overwhelming.
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'm trying to reduce object fatigue to increase test readability.
the issue is when reading you wonder what makeSubitems()
does to the list of things provided and have to go check. Encapsulation often does help, but in this case the transformation is so small (add a type: 'subitems'
) that the indirection doesn't seem worth it.
But this is minor and not worth haggling over where the mental tradeoff "really" is :)
// @ts-ignore: It's ok that there is no text. | ||
subRows = this._getCanonicalizedHeading(heading.subRows); | ||
if (!subRows.key) { | ||
subHeading = this._getCanonicalizedHeading(heading.subHeading); |
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.
wdyt about combining the subHeading
fixup here and the one down below (where the default values for valueType
, granularity
, etc are set) into a _getCanonicalizedSubHeading(subHeading, parentHeading)
(or whatever) called here or down there?
Puts the subHeading
overrides all in one place and makes _getCanonicalizedHeading
simpler since it won't need this second execution path within itself
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.
Best I could do was introduce two new functions, one for canonicalizing subHeading and another for deriving a header from a subHeading/parent.
} | ||
|
||
/** | ||
* Renders one or more rows from a details table item. |
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.
* Renders one or more rows from a details table item. | |
* Renders one or more rows (if there are subItems) from a details table item. |
for some context?
fragment.append(this._renderTableRow(item, headings)); | ||
|
||
// A single details item can expand into multiple table rows. These additional table rows | ||
// are called sub-rows. |
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 now to refer to sub-rows
but have the property checked immediately below be called subItems
. Same with subItems
in the LHR but lh-sub-row
in the CSS.
Should we commit to the items
mistake and go all in on sub-items
/lh-sub-items
?
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 missed updating this. and this comment was more useful here when the function was bigger and more complex. moved it to the function jsdoc.
* @param {LH.Audit.Details.OpportunityItem | LH.Audit.Details.TableItem} item | ||
* @param {LH.Audit.Details.OpportunityColumnHeading[]} headings | ||
*/ | ||
_renderTableItemRows(item, headings) { |
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.
can we come up with some naming options for _renderTableRow
and _renderTableItemRows
? :)
I assume _renderTableItemRows
is saying a table item can be a row or rows, depending on if it had subrows in it? But _renderTableItem
also sounds like a singular thing (like _renderTableValue
), not a row or rows...
_renderTableRowsFromItem
?
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.
what did you think of _renderTableRowsFromItem
? Or other permutations?
_renderTableItemRows
is kind of gibberish if you're not already in the mindspace of "table items
are rows, and each item can result in more than one row if it has subItems
"
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.
_renderTableRowsFromItem
sgtm!
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 love to code golf some of the details rendering more, but it might be a lot more productive for me to just make a follow up PR at some poin so you can move on to actually important changes :)
Just the comment and possible method rename left, otherwise LGTM!
types/audit-details.d.ts
Outdated
|
||
// TODO: drop TableColumnHeading, rename OpportunityColumnHeading to TableColumnHeading and | ||
// use that for all table-like audit details. | ||
|
||
export interface TableColumnHeading { | ||
/** | ||
* The name of the property within items being described. | ||
* If null, subRows must be defined, and the first sub-row will be empty. | ||
* If null, subHeading must be defined, and the first subItem row will be empty. |
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 the first subItem row will be empty
Can this be clarified? I don't remember what we came up with when we discussed what this was saying with @paulirish. There's no empty first subItem rows in any of the tests or expectations...
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.
tried to improve the comment.
writing these details renderer tests is cumbersome... I wish we just diffed HTML snapshots here :/
{url: 'https://www.example.com', sources: ['a', 'b', 'c']}, | ||
{ | ||
url: 'https://www.example.com', | ||
subItems: makeSubitems([ |
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'm trying to reduce object fatigue to increase test readability.
the issue is when reading you wonder what makeSubitems()
does to the list of things provided and have to go check. Encapsulation often does help, but in this case the transformation is so small (add a type: 'subitems'
) that the indirection doesn't seem worth it.
But this is minor and not worth haggling over where the mental tradeoff "really" is :)
* @param {LH.Audit.Details.OpportunityItem | LH.Audit.Details.TableItem} item | ||
* @param {LH.Audit.Details.OpportunityColumnHeading[]} headings | ||
*/ | ||
_renderTableItemRows(item, headings) { |
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.
what did you think of _renderTableRowsFromItem
? Or other permutations?
_renderTableItemRows
is kind of gibberish if you're not already in the mindspace of "table items
are rows, and each item can result in more than one row if it has subItems
"
lighthouse-cli/test/smokehouse/test-definitions/byte-efficiency/expectations.js
Outdated
Show resolved
Hide resolved
One last thing from me: Should |
oops |
oops? |
I had an outstanding discussion item and didn't realize the merge when green label was here when I fixed the tests. Nbd. |
Continuing from #10553
This is option 2 of @brendankenny's suggested changes to sub-rows, including the changes to the renderer to use it.