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(lhr): remove debugString, add explantion/errorMessage #5132

Merged
merged 5 commits into from
May 7, 2018

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented May 5, 2018

I am SUPER jazzed about this change. I think it cleans up the intention behind everything A LOT and is extra nice. There is no more debug string exposed at the audit level (manifest-parser still returns a debug string from gatherer but we can clean that up later). Existing debug strings got recategorized into one of

  1. displayValue - for cases like appcache where we just communicated the name of the thing we found
  2. errorMessage - when the message was a true error message/failure case
  3. warnings - for when the message was just a warning. This is the biggest behavioral change in the PR, the warnings are now collected and displayed in the top-level warnings instead of popping the specific audit into failing. I request that you only consider if warnings should be exposed per-audit in the LHR for this PR and not discuss the display mechanism we can always change how the warnings manifest in the report later, so let's just focus on the breaking-LHR-relevant change.
  4. explanation - the default case if the debugString didn't obviously fit into the other 3, these are currently displayed exactly as debugString was before, so no real impact other than name change. I have ideas for how to change the display but we can 🚲 🏠 that another day

NOTE: relies on #5128 and conflicts with #5130

@vinamratasingal-zz
Copy link

Not sure if my approval here is really needed but I'll give a LGTM anyways :P

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.

this is great. really like the semantic cleanup here.


Some of the new displayValue's don't appear to be making their way to the report:

before and after
image
image


if (audit.warnings.length) {
const prefixedWarnings = audit.warnings.map(msg => `${audit.description}: ${msg}`);
lighthouseRunWarnings.push(...prefixedWarnings);
Copy link
Member

Choose a reason for hiding this comment

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

all warnings are pushed to the toplevel warnings?

relatedly: i haven't seen a top level warning in the report in a long time. :)

Copy link
Collaborator Author

@patrickhulce patrickhulce May 6, 2018

Choose a reason for hiding this comment

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

all warnings are pushed to the toplevel warnings?

correct, I figure we can always change this without breaking LHR changes later if we don't like it/prefer to flag the individual audits, buuuuuut as you point out...

relatedly: i haven't seen a top level warning in the report in a long time. :)

agreed I can't remember seeing one naturally, so seems like a good time to try this out

only thing I can think of we might want to change is that the warnings entries are objects like {message: string} in the LHR so we can later add {level: } etc if we want

@@ -99,7 +99,8 @@ describe('PerfCategoryRenderer', () => {
assert.ok(oppSparklineElement.title, 'did not set tooltip on sparkline');
});

it('renders the performance opportunities with a debug string', () => {
// TODO(phulce): verify these don't happen anymore
it.skip('renders the performance opportunities with a debug string', () => {
Copy link
Member

Choose a reason for hiding this comment

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

in a branch of mine, i handle this case.

Copy link
Collaborator Author

@patrickhulce patrickhulce May 6, 2018

Choose a reason for hiding this comment

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

cool beans, in this case it's referring to the fact that it should exclusively be an "error" and that an explanation isn't really possible anymore (the error case is covered by the case below)

Copy link
Member

Choose a reason for hiding this comment

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

so, verified?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes indeed, removed

"debugString": "Audit error: Required RobotsTxt gatherer did not run.",
"displayValue": "",
"errorMessage": "Audit error: Required RobotsTxt gatherer did not run.",
"warnings": [],
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 leave warnings undefined if there are none?
same thing with displayValue, tbh. :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah sgtm 👍 @brendankenny agree?

Copy link
Member

@brendankenny brendankenny May 7, 2018

Choose a reason for hiding this comment

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

@brendankenny agree?

yeah, sounds good

@patrickhulce
Copy link
Collaborator Author

patrickhulce commented May 6, 2018

Hmmm strange @paulirish they're working fine for me, is this merged with some of your branches perhaps and mixing with the single-use displayValue bug?

image

@patrickhulce
Copy link
Collaborator Author

@paulirish diff is ~100 lines smaller with undefined warnings/displayValue 🎉

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.

I dig this. Over to brendan.

@patrickhulce patrickhulce changed the base branch from null_scores to master May 7, 2018 18:27
@brendankenny
Copy link
Member

travis/appveyor seem real confused

@patrickhulce
Copy link
Collaborator Author

travis/appveyor seem real confused

yeah I don't think they rebuild on change of base, just force pushed

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.

overally the change looks good and I like how much clearer things are for our bug vs their bug vs just a result from the audit :) A few major things for how we handle these different outputs:

  • it's great to start using displayValue for things that are display values, but it does expose a weakness with how we display them. It's definitely harder to scan across to the value for the audit vs just having it right below
    old:
    screen shot 2018-05-07 at 12 31 10
    new:
    screen shot 2018-05-07 at 12 31 18
    (and it's even wider across when not shrunk by github)

  • Separating the warnings from the audits seems like a regression from the status quo in most of the warnings cases added here. Having a list of images we can't reencode at the top of the report or (in the case of sample_v2.json) a warning that some target=_blank anchors may be outgoing but we can't tell, seems like noise at the top of the report and is lost as valuable context at the individual audit level (where you probably want to be warned that the audit may have been unable to comprehensively run its test).

Maybe having log levels for warnings make sense, and only things that audits flag as super important get moved to the top-level box, and everything else stays at the audit level?

@@ -99,7 +99,8 @@ describe('PerfCategoryRenderer', () => {
assert.ok(oppSparklineElement.title, 'did not set tooltip on sparkline');
});

it('renders the performance opportunities with a debug string', () => {
// TODO(phulce): verify these don't happen anymore
it.skip('renders the performance opportunities with a debug string', () => {
Copy link
Member

Choose a reason for hiding this comment

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

so, verified?

@@ -113,7 +113,8 @@ describe('CategoryRenderer', () => {
category.description = prevDesc;
});

it('renders audits with debugString as failed', () => {
// TODO(phulce): decide what to do about these cases
Copy link
Member

Choose a reason for hiding this comment

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

whats' the decision?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

updated the comment. this is what's up for debate re: toplevel warnings

currently the test simply doesn't apply anymore since all warnings are stuck into toplevel for display

@@ -182,7 +182,7 @@ class RobotsTxt extends Audit {
if (!status) {
return {
rawValue: false,
debugString: 'Lighthouse was unable to download your robots.txt file',
explanation: 'Lighthouse was unable to download your robots.txt file',
Copy link
Member

Choose a reason for hiding this comment

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

is this a failure case on our part or the site's?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

depends on what you mean by "our part" it could be because the server aborted the request/bad server/etc or it could be because the network failed, either way it seems to belong in explanation instead of errorMessage since there's nothing we would change code-wise, it's expected behavior

Copy link
Member

Choose a reason for hiding this comment

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

I guess this is the nuance we should expose so the user has some recourse (either file a bug on lighthouse or know how to start debugging their site). Really a bug on robots-txt gatherer so fine to leave

debugString = 'Lighthouse was unable to determine the destination ' +
'of some anchor tags. If they are not used as hyperlinks, ' +
'consider removing the _blank target.';
// TODO(phulce): make this message better with anchor.outerHTML
Copy link
Member

Choose a reason for hiding this comment

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

old message had a lot more explanation :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

fixed

@@ -167,7 +166,7 @@ class Audit {
result.rawValue = true;
}

if (result.error) {
if (result.errorMessage) {
Copy link
Member

Choose a reason for hiding this comment

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

time to rework re: #5128 (comment) ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

discussed in person, todo assigned to @brendankenny :)

@brendankenny
Copy link
Member

some of the TODOs clearly seem like for the future (e.g. debugString in gatherer output), but others seem like the needed to be decided soonish/in this PR? Sorry if i misclassified :)

@patrickhulce
Copy link
Collaborator Author

some of the TODOs clearly seem like for the future (e.g. debugString in gatherer output), but others seem like the needed to be decided soonish/in this PR? Sorry if i misclassified :)

yeah mostly just called out for discussion which it has sparked so 👍

only one remaining is in response to your other comments which we just discussed in person

It's definitely harder to scan across to the value for the audit vs just having it right below

We've definitely entered highly subjective territory here because I disagree 😄 Either way, we can always change where we put/color/highlight displayValue later on so we'll pickup discussion of best display value designs in a separate issue.

@patrickhulce
Copy link
Collaborator Author

filed #5153 @brendankenny 👍

@brendankenny
Copy link
Member

we can always change where we put/color/highlight displayValue later on so we'll pickup discussion of best display value designs in a separate issue.

yeah, it was just a comment on the display of displayValue. Out of scope with this PR

@paulirish paulirish mentioned this pull request May 7, 2018
82 tasks
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.

warnings/displayValue discussion moved to #5153

My only other concern would be making a warning out of e.g. every image in uses-optimized-images.js, but we can take that up in #5153ish

@brendankenny brendankenny merged commit 2c473e7 into master May 7, 2018
@brendankenny brendankenny deleted the no_debug_string branch May 7, 2018 22:20
kdzwinel pushed a commit to kdzwinel/lighthouse that referenced this pull request Aug 16, 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