-
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
treemap: first pass on Lighthouse Treemap #11545
Conversation
@@ -213,7 +213,15 @@ class ScriptTreemapDataAudit extends Audit { | |||
unusedBytes: unusedJavascriptSummary.sourcesWastedBytes[source], | |||
}; | |||
|
|||
const key = ModuleDuplication.normalizeSource(source); | |||
// ModuleDuplication uses keys without the source root prepended, but |
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.
Noticed an issue with the duplication stuff. Need to make a separate PR for this.
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.
do you mean split this fix out into a separate PR with tests or there's another fix not shown here that needs to happen in a different PR?
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.
First one. This is the fix.
@@ -27,6 +27,9 @@ | |||
|
|||
/** @typedef {import('./dom')} DOM */ | |||
|
|||
const VIEWER_ORIGIN = 'http://localhost:8000'; |
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.
Need a good way to control when to use localhost vs when to use the hosted app. Important for local development. Any ideas?
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.
We could append +dev
to our version marker when in local development that unlocks some extra stuff in the report?
import _Util = require('../app/src/util.js'); | ||
import {RootNodeContainer as _RootNodeContainer} from '../../lighthouse-core/audits/script-treemap-data'; | ||
import {Node as _Node} from '../../lighthouse-core/audits/script-treemap-data'; | ||
import '../../types/lhr'; |
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 feels wrong. Is it wrong?
// No UI for treemap yet. For now, must run this command in console. | ||
// @ts-ignore | ||
globalThis._tmpFeatures = features; | ||
const command = '_tmpFeatures._openTreemap();'; |
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.
Until there is a way to open the treemap viewer in the report, I wanted a way to do in simply through the console.
7c142a5
to
86772a7
Compare
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.
alright I started reviewing but I think there are still a few subcomponents we can break this up into to prevent a full page screenshots review situation :) I do appreciate being able to look at where it's headed though, very exciting!
taking a quick stab at substeps that might be nice:
- creating a basic treemap directory and page that dumps an LHR into a
<pre>
tag with a test (can discuss the build process, deployment, organization, etc) - adding in the report-ui-features logic to open an LHR from the report (can discuss the origin customization issues, commentary there)
- adding in the main treemap viewer logic to the page
each of those chunks feel like they have quite a bit to discuss on their own, WDYT?
@@ -213,7 +213,15 @@ class ScriptTreemapDataAudit extends Audit { | |||
unusedBytes: unusedJavascriptSummary.sourcesWastedBytes[source], | |||
}; | |||
|
|||
const key = ModuleDuplication.normalizeSource(source); | |||
// ModuleDuplication uses keys without the source root prepended, but |
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.
do you mean split this fix out into a separate PR with tests or there's another fix not shown here that needs to happen in a different PR?
@@ -27,6 +27,9 @@ | |||
|
|||
/** @typedef {import('./dom')} DOM */ | |||
|
|||
const VIEWER_ORIGIN = 'http://localhost:8000'; |
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.
We could append +dev
to our version marker when in local development that unlocks some extra stuff in the report?
@@ -27,6 +27,9 @@ | |||
|
|||
/** @typedef {import('./dom')} DOM */ | |||
|
|||
const VIEWER_ORIGIN = 'http://localhost:8000'; | |||
const TREEMAP_URL = `${VIEWER_ORIGIN}/treemap/`; |
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 is only when local though right? when deployed won't it be ${VIEWER_ORIGIN}/lighthouse/treemap/
?
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.
seems like the path and origin will be environment dependent
/** | ||
* Opens a new tab to an external page and sends data using postMessage. | ||
* @param {Object} data | ||
* @param {string} path |
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.
* @param {string} path | |
* @param {string} url |
|
||
/** | ||
* Opens a new tab to an external page and sends data using postMessage. | ||
* @param {Object} data |
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.
* @param {Object} data | |
* @template {{lhresult: LH.Result}} T | |
* @param {T} data |
(we should probably update viewer to accept lhr
though 😄 )
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.
lhresult
?
Planning to add a mode
property to the data sent to treemap app. At that point, there's no overlap in types, hence object. We don't do nothing but serialize this value, so it seems fine to me.
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.
lhresult?
Isn't that what viewer uses?
At that point, there's no overlap in types, hence object.
They both require an LHR, there could be some overlap in types if we wanted to.
We don't do nothing but serialize this value, so it seems fine to me.
I'm separately advocating elsewhere in this PR that we do do something with it ;)
lighthouse-treemap/README.md
Outdated
# in separate terminal, start build watch | ||
find lighthouse-treemap | entr -s 'DEBUG=1 yarn build-treemap' | ||
|
||
# visit http://localhost:8000/treemap/?debug |
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.
# visit http://localhost:8000/treemap/?debug | |
open http://localhost:8000/treemap/?debug |
:)
yarn serve-treemap | ||
|
||
# in separate terminal, start build watch | ||
find lighthouse-treemap | entr -s 'DEBUG=1 yarn build-treemap' |
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.
is this a new dependency we need to add to CONTRIBUTING.md?
$ which entr
entr not found
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.
No, that doesn't seem important to add there. I'll just add a comment here brew install entr
.
<span class="lh-header--url"></span> • <span class="lh-header--size lh-text-dim"></span></span> | ||
</span> | ||
<div class="panel panel--modals"> | ||
<!-- View modes go here --> |
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.
maybe use an id
for component slots?
} | ||
|
||
render() { | ||
webtreemap.render(this.el, this.currentRootNode, { |
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.
I guess we own webtreemap, so you're confident we can customize this as much as we need for our purposes?
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.
Yes.
See the spacing in the PR image. Note that I'm waiting on @paulirish to publish a new version that supports the
Could, do you think the associated code is worth separating?
idk |
No, not anymore once I started reviewing and came up with a much larger 3-way split :) |
ref #11254
This is a first pass of the Lighthouse Treemap app, with minimal features. See https://github.com/GoogleChrome/lighthouse/compare/viewer-treemap-2 for a rough WIP view of what the app might look like with all features intact.
I ripped out a ton of code/features to make a simpler initial PR to review. Please point out if I missed something that could be deferred for later.
Please note that there's quite a bit of design work left to do. I've got the rough look and structure down, but in total it's too much for an initial PR, so let's defer most of it for now.
https://lighthouse-chk0pd53k.vercel.app/treemap/?debug (won't have spacing, waiting on @paulirish to publish webtreemap package)