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: unknown details type #9557

Merged
merged 7 commits into from
Sep 14, 2019
Merged

report: unknown details type #9557

merged 7 commits into from
Sep 14, 2019

Conversation

connorjclark
Copy link
Collaborator

We currently throw on unknown details types. This means that any new details type is a breaking change.

So instead, let's just show the data with a warning message.

image

image

@connorjclark
Copy link
Collaborator Author

connorjclark commented Aug 14, 2019

Maybe summary should be shorter (just "Unknown"). Otherwise would make small, unknown columns really really big.

@paulirish
Copy link
Member

oof yah. this hurts.

image

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.

LGTM.

This seems like a positive change for renderers in the future, but should be a no-op now afaict.

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.

yah good call on this.

have some revised text for the error msg.

image

console.error(`Unknown valueType: ${type}`, value);
const element = this._dom.createElement('details', 'lh-unknown');
this._dom.createChildOf(element, 'summary').textContent =
`Details type '${type}' unrecognized by this version of the report renderer.`;
Copy link
Member

Choose a reason for hiding this comment

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

`Ruh roh! 😿 We don't know how to render audit details of type \`${type}\`. The Lighthouse version that collected this data is likely newer than the Lighthouse version of the report renderer. Expand for the raw JSON.`

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 not include the Ruh roh! please :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Having long text here will be bad if the unknown type is in a table. Thoughts on just "Unknown" -> expand -> see the message you have here followed by the JSON?

Copy link
Member

Choose a reason for hiding this comment

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

Having long text here will be bad if the unknown type is in a table. Thoughts on just "Unknown" -> expand -> see the message you have here followed by the JSON?

how does the pre-box look in that case (especially if there's one on each row or whatever)? Inside a table may be a lost cause regardless

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Inside a table may be a lost cause regardless

yea, I guess this is fine then.

lighthouse-core/report/html/renderer/details-renderer.js Outdated Show resolved Hide resolved
@brendankenny
Copy link
Member

brendankenny commented Sep 13, 2019

oof yah. this hurts.

I mean, there was a reason for this. After this no one is going to notice if you accidentally trick tsc with a cast and try to have a criticalrequestchains or filmstripz details type because the result is collapsed in an audit somewhere.

Same with web.dev. Why update the report renderer if it's working...meanwhile after source-location anyone using deprecations and font-size audits are going to get unstyled json.

The actual right call is to only add details types on breaking changes, but if we're not willing to do that (yet), then this is probably the best we can do.

// @ts-ignore tsc thinks this unreachable, but ts-ignore for error message just in case.
const detailsType = details.type;
throw new Error(`Unknown type: ${detailsType}`);
// Tsc thinks this is unreachable. But renderers should be forward compatible with new unexpected detail types.
Copy link
Member

Choose a reason for hiding this comment

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

@exterkamp hates indentation, apparently

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ya he do

Copy link
Member

Choose a reason for hiding this comment

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

rt, don't like it

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.

reluctant LGTM but this will be an improvement :)

lighthouse-core/report/html/renderer/details-renderer.js Outdated Show resolved Hide resolved
lighthouse-core/report/html/renderer/details-renderer.js Outdated Show resolved Hide resolved
console.error(`Unknown valueType: ${type}`, value);
const element = this._dom.createElement('details', 'lh-unknown');
this._dom.createChildOf(element, 'summary').textContent =
`Details type '${type}' unrecognized by this version of the report renderer.`;
Copy link
Member

Choose a reason for hiding this comment

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

this should be on Util.UIStrings, probably?

Copy link
Member

Choose a reason for hiding this comment

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

It can be if we modify it to not use ICU. If we want to add a {type} we need someway of jamming i18n into the report. #9166

I suggest leaving this not translated, add a TODO referring to #7238, and then we can handle it in a follow up that allows ICU in the report.

@vercel vercel bot temporarily deployed to staging September 13, 2019 20:57 Inactive
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.

❤️ it

@connorjclark
Copy link
Collaborator Author

After this no one is going to notice if you accidentally trick tsc with a cast and try to have a criticalrequestchains or filmstripz details type because the result is collapsed in an audit somewhere.

do we have any tests that check for console error messages in the report?

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