-
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
report: unknown details type #9557
Conversation
Maybe summary should be shorter (just "Unknown"). Otherwise would make small, unknown columns really really big. |
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.
LGTM.
This seems like a positive change for renderers in the future, but should be a no-op now afaict.
Co-Authored-By: Shane Exterkamp <shaneexterkamp5@gmail.com>
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.
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.`; |
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.
`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.`
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 not include the Ruh roh!
please :)
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.
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?
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.
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
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.
Inside a table may be a lost cause regardless
yea, I guess this is fine then.
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 Same with 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. |
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.
@exterkamp hates indentation, apparently
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.
ya he do
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.
rt, don't like it
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.
reluctant LGTM but this will be an improvement :)
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.`; |
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 should be on Util.UIStrings
, probably?
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.
Co-Authored-By: Brendan Kenny <bckenny@gmail.com>
Co-Authored-By: Paul Irish <paulirish@google.com>
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.
❤️ it
do we have any tests that check for console error messages in the report? |
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.