Skip to content

report: autogenerate components.js from templates.html#12803

Merged
connorjclark merged 55 commits into
masterfrom
components
Aug 9, 2021
Merged

report: autogenerate components.js from templates.html#12803
connorjclark merged 55 commits into
masterfrom
components

Conversation

@connorjclark

@connorjclark connorjclark commented Jul 19, 2021

Copy link
Copy Markdown
Collaborator

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

@patrickhulce patrickhulce left a comment

Copy link
Copy Markdown
Collaborator

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!

Comment thread package.json
"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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Contributor

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

Comment thread build/build-report-components.js Outdated
Comment thread report/assets/styles.css

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

Copy link
Copy Markdown
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
Copy Markdown
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.

Comment thread report/renderer/dom.js
if (template.hasAttribute('data-stamped')) {
this.findAll('style', clone).forEach(style => style.remove());
createComponent(componentName) {
let component = this._componentCache.get(componentName);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

bump :)

.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
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

🎉

Comment thread build/build-report-components.js Outdated
Comment thread build/build-report-components.js Outdated
Comment thread report/renderer/components.js Outdated
Comment thread build/build-dt-report-resources.js
Comment thread report/test/renderer/components-test.js Outdated
Comment thread build/build-report-components.js Outdated
previousSiblingElement && nextSiblingElement &&
(previousSiblingElement.tagName === 'SPAN' || nextSiblingElement.tagName === 'SPAN')
);
if (!allowJustWhitespace) return;

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
Contributor

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
Copy Markdown
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.

Comment thread report/test/renderer/components-test.js Outdated
Comment thread lighthouse-core/gather/driver/execution-context.js Outdated
@connorjclark

connorjclark commented Aug 6, 2021

Copy link
Copy Markdown
Collaborator Author

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

SGTM @connorjclark !

@brendankenny

brendankenny commented Aug 7, 2021

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
Contributor

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