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

treemap: first pass on Lighthouse Treemap #11545

Closed
wants to merge 8 commits into from
Closed

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Oct 9, 2020

ref #11254

image

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)

@connorjclark connorjclark requested a review from a team as a code owner October 9, 2020 23:47
@connorjclark connorjclark requested review from paulirish and removed request for a team October 9, 2020 23:47
@@ -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
Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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';
Copy link
Collaborator Author

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?

Copy link
Collaborator

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';
Copy link
Collaborator Author

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();';
Copy link
Collaborator Author

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.

@patrickhulce
Copy link
Collaborator

flushing usability notes first (may or may not be solved by upcoming design, just want to make sure they don't get lost when we get to that step if we punt 😃 )

  • bundles are really hard to distinguish, just kinda looks like one giant treemap (I think the design accounted for this somehow, but this is way more important than I realized)

  • "All" button in top right has cursor pointer but doesn't seem to do anything yet or have a purpose without the other views, puntable?

  • the hover border can get hidden sometimes, z-index issue or something maybe?
    image
    image

  • the rest feels identical to my normal treemaping experience which I'm already very familiar with so I'm probably not the best reviewer to find usability problems there :)

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.

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
Copy link
Collaborator

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';
Copy link
Collaborator

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/`;
Copy link
Collaborator

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/?

Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* @param {string} path
* @param {string} url


/**
* Opens a new tab to an external page and sends data using postMessage.
* @param {Object} data
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* @param {Object} data
* @template {{lhresult: LH.Result}} T
* @param {T} data

(we should probably update viewer to accept lhr though 😄 )

Copy link
Collaborator Author

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.

Copy link
Collaborator

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 ;)

# in separate terminal, start build watch
find lighthouse-treemap | entr -s 'DEBUG=1 yarn build-treemap'

# visit http://localhost:8000/treemap/?debug
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
# 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'
Copy link
Collaborator

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

Copy link
Collaborator Author

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.

build/build-treemap.js Outdated Show resolved Hide resolved
build/build-treemap.js Outdated Show resolved Hide resolved
<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 -->
Copy link
Collaborator

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, {
Copy link
Collaborator

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?

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.

@connorjclark
Copy link
Collaborator Author

flushing usability notes first (may or may not be solved by upcoming design, just want to make sure they don't get lost when we get to that step if we punt 😃 )

  • bundles are really hard to distinguish, just kinda looks like one giant treemap (I think the design accounted for this somehow, but this is way more important than I realized)

See the spacing in the PR image. Note that I'm waiting on @paulirish to publish a new version that supports the spacing option. Until then, yea it is all bunched up and awful.

  • "All" button in top right has cursor pointer but doesn't seem to do anything yet or have a purpose without the other views, puntable?

Could, do you think the associated code is worth separating?

  • the hover border can get hidden sometimes, z-index issue or something maybe?

idk

@patrickhulce
Copy link
Collaborator

Could, do you think the associated code is worth separating?

No, not anymore once I started reviewing and came up with a much larger 3-way split :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants