report: autogenerate components.js from templates.html#12803
Conversation
…house into make-component-script
patrickhulce
left a comment
There was a problem hiding this comment.
a few outstanding questions, but LGTM!
| "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", |
There was a problem hiding this comment.
so now every yarn start we're running eslint? 😞
reminder me again why a watch is terrible? 😅
There was a problem hiding this comment.
There was a problem hiding this comment.
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 :)
|
|
||
| .lh-gauge-base { | ||
| opacity: 0.1; | ||
| stroke: var(--circle-background); |
There was a problem hiding this comment.
these intentionally removed? having trouble seeing how these are related
There was a problem hiding this comment.
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); |
| .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 |
| previousSiblingElement && nextSiblingElement && | ||
| (previousSiblingElement.tagName === 'SPAN' || nextSiblingElement.tagName === 'SPAN') | ||
| ); | ||
| if (!allowJustWhitespace) return; |
There was a problem hiding this comment.
is there any harm in always collapsing whitespace to a single ' ' (except for <pre> , etc) and not keeping the heuristic? A longer components.js?
There was a problem hiding this comment.
much longer ... although I last checked that before aggregating appending nodes to a single .append. Can check again.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Latest commit has this change.
|
I think this is landable.
Anything else? |
|
SGTM @connorjclark ! |
|
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 We can also decide that later if need be. I can imagine you're eager to land and no longer maintain this branch :) |
|
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 |
yeah, I'm wondering if it's going to be the next "person x, you have to run |

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.
templates.htmlindefinitely–it remains our source of truth for these "components"dom.createComponentdom.createComponentacts likedom.cloneTemplate–gets the template, caches it, and stripsstyletag if necessarytemplateContext(still left to do):