Conversation
|
|
||
|
|
||
| const headings = [ | ||
| {key: 'url', itemType: 'url', text: 'URL'}, |
There was a problem hiding this comment.
we can override this per row correct? it'd be nice to finally have a nice solution for displaying the inline code preview in the url column
There was a problem hiding this comment.
to have an individual row change the itemType? that seems a little weird. whyd we want diff itemtypes in the column?
There was a problem hiding this comment.
in all the css-based ones the "url column" doesn't always have a url and it's a code snippet preview instead since it's an inline style. it'd be nice to have the details renderer support that too so the code snippets can say {type: "code", content: ".inline-style {...}"} or something
| totalKb: 'Original', | ||
| potentialSavings: 'Potential Savings', | ||
| } | ||
| headings, |
There was a problem hiding this comment.
The @return docstring of this method needs to be updated to match.
|
|
||
|
|
||
| /** | ||
| * @param {!DetailsRenderer.TableDetailsJSON} details |
There was a problem hiding this comment.
is TableDetailsJSON typedef'd anywhere? not seeing it.
| _renderThumbnail(obj) { | ||
| const element = this._dom.createElement('img', 'lh-thumbnail'); | ||
| element.src = obj.text.url; | ||
| // ignore obj.text.mimeType |
There was a problem hiding this comment.
Should we also add element.title = obj.text.url; so there's a full url when users hover over the image?
| * @return {!Element} | ||
| */ | ||
| _renderTable(details) { | ||
| const element = this._dom.createElement('details', 'lh-details', {open: true}); |
There was a problem hiding this comment.
should we open by default? There could be a lot of stuff in the table.
There was a problem hiding this comment.
nah. was only for development. will remove. :)
| element.appendChild(this._dom.createElement('summary')).textContent = details.header; | ||
| } | ||
|
|
||
| const tableElem = element.createChild('table', 'lh-table lh-table__multicolumn'); |
There was a problem hiding this comment.
Do you need lh-table__multicolumn? That was an impl detail of v1's handlebars table.
| * @return {!Element} | ||
| */ | ||
| self.Element.prototype.createChild = function(elementName, className) { | ||
| const element = instance.createElement(elementName, className); |
There was a problem hiding this comment.
pipe through the attrs param too?
There was a problem hiding this comment.
i dont think we can because in devtools this method will already exist and it doesnt do attrs
| self.Element.prototype.createChild = function(elementName, className) { | ||
| const element = instance.createElement(elementName, className); | ||
| this.appendChild(element); | ||
| return element; |
There was a problem hiding this comment.
nit: return this.appendChild(element);
| * @param {string=} className | ||
| * @return {!Element} | ||
| */ | ||
| self.Element.prototype.createChild = function(elementName, className) { |
There was a problem hiding this comment.
If we're comfortable with modifying built in prototypes, then I have a bunch of other helpers to add :)
There was a problem hiding this comment.
check out https://github.com/ChromeDevTools/devtools-frontend/blob/master/front_end/dom_extension/DOMExtension.js .. we can polyfill whatever from there we want. (or easier: just load that file in the report)
| --image-preview: 24px; | ||
| } | ||
|
|
||
| img.lh-thumbnail { |
There was a problem hiding this comment.
just .lh-thumbnail? Seems ok to be tag-agnostic.
| * @param {string=} className | ||
| * @return {!Element} | ||
| */ | ||
| self.Element.prototype.createChild = function(elementName, className) { |
There was a problem hiding this comment.
why not just make this a method on DOM? We add five characters (DOM and a , ) but avoid all the usual downsides of doing this. Also has the benefit that Closure will understand it when not compiled with devtools, we can more easily test it, etc
lighthouse-core/audits/audit.js
Outdated
| } | ||
|
|
||
| /** | ||
| * @param {!Audit.Headings} headings |
There was a problem hiding this comment.
@return {!Array<string>}?
lighthouse-core/audits/audit.js
Outdated
| } | ||
|
|
||
| /** | ||
| * @param {!Audit.Headings} headings |
There was a problem hiding this comment.
hmm, definitely not an object. {!Array<!Object<string, string>>}? It's hard to follow the old createTable helper
| }); | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
just one space (here and elsewhere). Is this a vscode setting that needs to be changed?
There was a problem hiding this comment.
heh. yah https://github.com/Microsoft/vscode-comment is at fault. reported the bug.
fixed
lighthouse-core/audits/audit.js
Outdated
| } | ||
|
|
||
| /** | ||
| * @param {!Audit.Headings} headings |
There was a problem hiding this comment.
this is fine for now, but it won't actually work if we were to turn on type checking on this file. Closure won't be able to see the typedef since it's in another module. We'll have to think of how we want to do that (move report typedefs to their own file?)
lighthouse-core/audits/audit.js
Outdated
| } | ||
|
|
||
| /** | ||
| * @param {!Audit.Headings} headings |
There was a problem hiding this comment.
same type as above results
lighthouse-core/audits/audit.js
Outdated
| */ | ||
| Audit.Heading; // eslint-disable-line no-unused-expressions | ||
|
|
||
| /** @typedef {!Array<!Audit.Heading>} */ |
There was a problem hiding this comment.
is it worth making a typedef for this?
There was a problem hiding this comment.
Actually yeah. Basically we pass around this typedef and never use the Audit.Heading one directly. Not entirely worth it to nuke this guy, i tried.
There was a problem hiding this comment.
if that's the case, what about
/** @typedef {
* !Array<{
* key: string,
* itemType: string,
* text: string,
* }>}
*/
Audit.Headings;and skip Audit.Heading?
| * @return {!Element} | ||
| */ | ||
| _renderThumbnail(obj) { | ||
| const element = this._dom.createElement('img', 'lh-thumbnail'); |
There was a problem hiding this comment.
this isn't a thing on DetailsJSON
| static makeV2TableRows(headings, results) { | ||
| const tableRows = results.map(item => { | ||
| return headings.map(heading => { | ||
| return { |
There was a problem hiding this comment.
why not do this in _renderTable rather than in the JSON report?
There was a problem hiding this comment.
shrugz
I'm okay with either.
patrick is fine with either but thinks its slightly better to have all things coming into renderer be our details objects
dgozman also feels the same way, and thinks that if we wanted to conserve the size of the LH object we should shorten type to t etc. ;) ;)
so I'm comfortable expanding the objects over here before we deliver the LHR.
There was a problem hiding this comment.
so I'm comfortable expanding the objects over here before we deliver the LHR.
I think with our less rigid details taxonomy now I'm actually more OK with this extra verboseness :)
We can keep an eye on report file size and how much is taken up by "type": "text" and figure out some defaults (default to text or default to header itemType) if/when needed
paulirish
left a comment
There was a problem hiding this comment.
note from sync: default item details type should be text, handled as such in the details-renderer
| }); | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
heh. yah https://github.com/Microsoft/vscode-comment is at fault. reported the bug.
fixed
|
@paulirish how's this coming? We've got a lot of audits that need this guy. |
roger that. on it. |
bc73833 to
160e6ef
Compare
|
PTAL. updated. |
| static makeV2TableRows(headings, results) { | ||
| const tableRows = results.map(item => { | ||
| return headings.map(heading => { | ||
| const value = item[heading.key]; |
| } | ||
|
|
||
| .lh-table { | ||
| --image-preview: 24px; |
There was a problem hiding this comment.
nit: --image-preview-size or something?
|
@brendankenny to you |
| * type: string, | ||
| * header: ({text: string}|undefined), | ||
| * items: !Array<!Array<!DetailsRenderer.DetailsJSON>>, | ||
| * itemHeaders: !Array<!DetailsRenderer.DetailsJSON> |
There was a problem hiding this comment.
by letting these be DetailsJSON we're basically descending into recursive madness again since in theory when you call this.render on them they could embed a whole other table (but of course, our css would quickly fall over itself if that sort of thing occurred). This leaves these basically untyped (except our assurance to the compiler that we're correct when we cast in this.render)
I'm not sure of the right solution...maybe we could separate top level rendering (anything currently in this.render) from more primitive-level rendering (just text, url, and thumbnail as of this PR) in a future PR or something, but we would need to make whatever we did non-annoying.
There was a problem hiding this comment.
we're basically descending into recursive madness again
are we though?
detailsjson only has type and text.. it can't contain other types.
really it and thumbnail should include the word "item" as they are ALWAYS leaf nodes.
and the render() method should accept all of these leaf & group types. the real bug seems that render's param is typed to a leaf node when we know its not.
There was a problem hiding this comment.
detailsjson is the base (structural) type that is the superset of all of them. It only has fields all of them have: type and optional text (really text is there from when they all had text and should probably be removed). render() takes that and casts according to its type to the appropriate type, and we'll take responsibility to make sure that if type is set to x, then that object really is of type x. It's a hack, but simple (we only have to have humans in the loop checking the top level details object), and can easily be reworked once we know the full outlines of the types we need.
Allowing arbitrary nesting means that it's much less simple since we have to guarantee that all the nested items and itemHeaders are really whatever their type says. It also means we're implicitly breaking the no-typedef-cycles, just getting around it by casting, which is what I meant by recursive madness.
If you're saying we should have a different type explicitly for leaf nodes to make this better, I think that's great
There was a problem hiding this comment.
ya makes sense. let's sort this out in voice as i have a few ideas.
| * @param {!DetailsRenderer.ThumbnailDetails} value | ||
| * @return {!Element} | ||
| */ | ||
| _renderThumbnail(value) { |
There was a problem hiding this comment.
make a note of this in a jsdoc description?
| } | ||
|
|
||
| const element = this._dom.createElement('img', 'lh-thumbnail'); | ||
| element.src = value.url; |
There was a problem hiding this comment.
was matching our v1. :) i changed it to empty string, which seems better, actually.
| * @param {!Artifacts} artifacts | ||
| * @return {{results: !Array<Object>, tableHeadings: Object, | ||
| * passes: boolean=, debugString: string=}} | ||
| * @return {{results: !Array<Object>, headings: !Audit.Headings, passes: boolean=, debugString: string=}} |
There was a problem hiding this comment.
boolean= would be (boolean|undefined), but doesn't look like it can be undefined?
string= would be (string|undefined)
(= only works for @params...technically it means optional param, which just so happens to manifest as being undefined)
There was a problem hiding this comment.
thanks. made a new typdef for this guy since he was everywhere.
| * @param {!Artifacts} artifacts | ||
| * @param {number} networkThroughput | ||
| * @return {!AuditResult} | ||
| * @return {{results: !Array<Object>, passes: boolean=, headings: !Audit.Headings, debugString: string=}} |
| * @param {!Artifacts} artifacts | ||
| * @return {{results: !Array<Object>, tableHeadings: Object, | ||
| * passes: boolean=, debugString: string=}} | ||
| * @return {{results: !Array<Object>, headings: !Audit.Headings, passes: boolean=, debugString: string=}} |
| * @param {!Artifacts} artifacts | ||
| * @return {{results: !Array<Object>, tableHeadings: Object, | ||
| * passes: boolean=, debugString: string=}} | ||
| * @return {{results: !Array<Object>, headings: !Audit.Headings, debugString: string=}} |
lighthouse-core/audits/audit.js
Outdated
| */ | ||
| Audit.Heading; // eslint-disable-line no-unused-expressions | ||
|
|
||
| /** @typedef {!Array<!Audit.Heading>} */ |
There was a problem hiding this comment.
if that's the case, what about
/** @typedef {
* !Array<{
* key: string,
* itemType: string,
* text: string,
* }>}
*/
Audit.Headings;and skip Audit.Heading?
| static makeV2TableRows(headings, results) { | ||
| const tableRows = results.map(item => { | ||
| return headings.map(heading => { | ||
| const value = item[heading.key]; |
There was a problem hiding this comment.
results values might not just be a string, then?
It's not very pretty but the basics are there.
AuditResult.details.itemHeadersfor thetheadcellsscreenshot, lol:
