report: templates refactor#12759
Conversation
|
At first blush (and subsequent ones...) this seems unmaintainable. Making such complex DOM with raw JS is pretty impossible to read. This will really burden future renderer changes. Did you look into transforming (programmatically) the HTML we already have into a valid google3 template file? I don't have a full picture on how it'd work, and we'd still have to stub out Another approach might be to create these "components" from our authored-html. Perhaps we can generate Or, is there some web component library that would work well for us? |
patrickhulce
left a comment
There was a problem hiding this comment.
Woohoo let's do this! 🎉
high-level thoughts:
the styles that lives in templates.html move to the complete styles.css. (These styles were also adding extra headaches for some embedders ;)
great, love it 👍
created a lazy & cached thing to get the components. same basic effect as what cloneTemplate did.
i left out the unit test changes, but they're very straightforward and boring.
cool cool cool
created template components for 4 examples. scorescale, audit, opportunity, topbar.
Separating into JS sounds great, but I find this much harder to read and edit compared to the current template system or other alternatives like tagged template literals or JSX :/ (the SVG element creation is a particularly rough example of this IMO). Apologies for being out of the loop but do we have the embedder API requirements doc to be able to have a better idea if either of those might be an option?
|
paul and I been working on this: https://github.com/GoogleChrome/lighthouse/compare/master..make-component-script |
|
now replaced with the approach in #12803 |
Currently a number of "component"s have their HTML source defined in report/assets/templates.html. However, for many embedders, including that file in the build process creates some challenges.. especially when we want to easily roll the latest Lighthouse somewhere.
I'm proposing a refactor for the stuff in
templates.html: build out those items with standard DOM calls. We're already using this pattern pretty heavily in the report.In this PR:
looking for any high-level feedback on this approach.