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: autogenerate components.js from templates.html #12803

Merged
merged 55 commits into from
Aug 9, 2021
Merged

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Jul 19, 2021

ref #12759

This autogenerates JS functions that make HTML components from the templates.html. This simplifies the renderer code (no need to bundle the HTML / ship a HTML file) and removes some global state management (we stored global state in the DOM via data-stamped).

The main motivation here is to satisfy constraints for using the renderer in a new internal google3 project.

  • keep templates.html indefinitely–it remains our source of truth for these "components"
  • rename template ids to be camelCase. These ids are used in dom.createComponent
  • dom.createComponent acts like dom.cloneTemplate–gets the template, caches it, and strips style tag if necessary
  • delete templateContext
  • move nested templates to be their own thing. simplifies the component generation

(still left to do):

  • Fix jest tests
  • Update build steps for CDT/PSI

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.

a few outstanding questions, but LGTM!

@@ -23,7 +23,7 @@
"build-smokehouse-bundle": "node ./build/build-smokehouse-bundle.js",
"build-lr": "yarn reset-link && node ./build/build-lightrider-bundles.js",
"build-pack": "bash build/build-pack.sh",
"build-report": "node build/build-report.js",
"build-report": "node build/build-report-components.js && yarn eslint --fix report/renderer/components.js && node build/build-report.js",
Copy link
Collaborator

Choose a reason for hiding this comment

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

so now every yarn start we're running eslint? 😞

reminder me again why a watch is terrible? 😅

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

running eslint on one file, it just takes a second
image

why a watch is terrible?

Extra hoops to jump through for development is never good. running yarn start ... is simpler than remembering to open a new terminal and run a watch command

don't feel strongly. i say we vote on it.

Copy link
Member

Choose a reason for hiding this comment

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

The watch question is a good one (as someone who generally dislikes watch commands :) and we should definitely look at what we're doing in all our build steps and the efficiency of them, but this seems ok until we have #12689 mostly settled and know more of the lay of the land?

Personally I've been spoiled by esbuild and would love to get building everything down to like < 1s total, but we'll see what's possible :)

build/build-report-components.js Outdated Show resolved Hide resolved
@@ -1168,16 +1168,14 @@
}

.lh-gauge-base {
opacity: 0.1;
stroke: var(--circle-background);
Copy link
Collaborator

Choose a reason for hiding this comment

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

these intentionally removed? having trouble seeing how these are related

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

these variables do not exist. not related, just found during debugging.

if (template.hasAttribute('data-stamped')) {
this.findAll('style', clone).forEach(style => style.remove());
createComponent(componentName) {
let component = this._componentCache.get(componentName);
Copy link
Collaborator

Choose a reason for hiding this comment

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

bump :)

@@ -37,12 +37,14 @@ class ReportGenerator {
.replace(/</g, '\\u003c') // replaces opening script tags
.replace(/\u2028/g, '\\u2028') // replaces line separators ()
.replace(/\u2029/g, '\\u2029'); // replaces paragraph separators
// terser does its own sanitization, but keep this basic replace for when
Copy link
Collaborator

Choose a reason for hiding this comment

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

🎉

build/build-report-components.js Outdated Show resolved Hide resolved
build/build-report-components.js Outdated Show resolved Hide resolved
report/renderer/components.js Outdated Show resolved Hide resolved
build/build-dt-report-resources.js Show resolved Hide resolved
report/test/renderer/components-test.js Outdated Show resolved Hide resolved
previousSiblingElement && nextSiblingElement &&
(previousSiblingElement.tagName === 'SPAN' || nextSiblingElement.tagName === 'SPAN')
);
if (!allowJustWhitespace) return;
Copy link
Member

Choose a reason for hiding this comment

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

is there any harm in always collapsing whitespace to a single ' ' (except for <pre> , etc) and not keeping the heuristic? A longer components.js?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

much longer ... although I last checked that before aggregating appending nodes to a single .append. Can check again.

Copy link
Member

Choose a reason for hiding this comment

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

much longer ... although I last checked that before aggregating appending nodes to a single .append. Can check again.

yeah, I can see that. Reading https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Whitespace, though, it's a lot more complicated than I thought it was, and it seems like detecting span is not sufficient, though maybe it is for the current form of our templates. It does seem easier to collapse all whitespace regardless of context (at a loss of file size, but maybe not too much?) and not have to figure it all out/test every case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Latest commit has this change.

report/test/renderer/components-test.js Outdated Show resolved Hide resolved
lighthouse-core/gather/driver/execution-context.js Outdated Show resolved Hide resolved
@connorjclark
Copy link
Collaborator Author

connorjclark commented Aug 6, 2021

I think this is landable.

  • We may come back to address the "watch/no watch" thing later down the line, once we've more time with the new esmodules/report must be built world.
  • There's minor contention regarding if caching is necessary: the complexity is scoped very narrowly to just one function/a couple lines in dom.js, at worst it is of zero benefit, and it's persisting the previous caching behavior, so I think it's fine to land now and if either of these assumptions prove to be wrong we can remove later on.

Anything else?

@patrickhulce
Copy link
Collaborator

SGTM @connorjclark !

@brendankenny
Copy link
Member

brendankenny commented Aug 7, 2021

The caching question was resolved well enough for me too, sorry if that wasn't clear. SGTM as well.

I did mean to ask if we should still be checking in report/renderer/components.js since it's part of yarn build-report now? Should we treat it like the other built report artifact(s) instead? That would avoid having to remember to run build-report after any changes to templates.html before committing/pushing.

We can also decide that later if need be. I can imagine you're eager to land and no longer maintain this branch :)

@connorjclark
Copy link
Collaborator Author

For me, the git check we do in CI is enough. I do prefer being able to see diffs of generated code, as it makes reviewing changes to the generator easier. We also have the "check in generated files" pattern for the CDT SourceMap.js, although in that case we decided to put it in a folder called generated.

@brendankenny
Copy link
Member

For me, the git check we do in CI is enough. I do prefer being able to see diffs of generated code, as it makes reviewing changes to the generator easier. We also have the "check in generated files" pattern for the CDT SourceMap.js, although in that case we decided to put it in a folder called generated.

yeah, I'm wondering if it's going to be the next "person x, you have to run yarn update:sample-json to get rid of those CI errors in your PR", but I'm good with this way for now. We don't update templates.html very often, so it may be totally fine.

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.

5 participants