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: subRow refactor, rename to subItem #10867

Merged
merged 17 commits into from
Jun 8, 2020
Merged

core: subRow refactor, rename to subItem #10867

merged 17 commits into from
Jun 8, 2020

Conversation

connorjclark
Copy link
Collaborator

Continuing from #10553

This is option 2 of @brendankenny's suggested changes to sub-rows, including the changes to the renderer to use it.

@connorjclark connorjclark requested a review from a team as a code owner May 29, 2020 01:20
@connorjclark connorjclark requested review from Beytoven and removed request for a team May 29, 2020 01:20
@googlebot
Copy link

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@@ -116,7 +122,8 @@ declare global {

export interface TableItem {
debugData?: DebugData;
[p: string]: undefined | ItemValue | ItemValue[];
subRows?: TableSubRows;
Copy link
Collaborator Author

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?

Copy link
Member

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

Copy link
Collaborator Author

@connorjclark connorjclark May 29, 2020

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?

@patrickhulce @paulirish

Copy link
Collaborator

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 ;)

#10084 (review)

@brendankenny
Copy link
Member

@googlebot I consent.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@connorjclark connorjclark changed the title core: sub-row refactor core: subRow refactor, rename to subItem May 30, 2020
'2191 +/- 50',
'2182 +/- 50',
'1259 +/- 50',
subItems: [
Copy link
Contributor

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!

Copy link
Member

@brendankenny brendankenny left a 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!


// 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.
Copy link
Member

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 :)

Copy link
Collaborator Author

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([
Copy link
Member

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 :)

Copy link
Collaborator Author

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.

Copy link
Member

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

@brendankenny brendankenny Jun 1, 2020

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

Copy link
Collaborator Author

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.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* 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.
Copy link
Member

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?

Copy link
Collaborator Author

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

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?

Copy link
Member

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"

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

_renderTableRowsFromItem sgtm!

Copy link
Member

@brendankenny brendankenny left a 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!


// 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.
Copy link
Member

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...

Copy link
Collaborator Author

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([
Copy link
Member

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

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"

@connorjclark
Copy link
Collaborator Author

One last thing from me:

Should subHeading be named subItemsHeading?

@connorjclark
Copy link
Collaborator Author

oops

@brendankenny
Copy link
Member

oops?

@connorjclark
Copy link
Collaborator Author

I had an outstanding discussion item and didn't realize the merge when green label was here when I fixed the tests. Nbd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants