Investigate generating self-contained brick.js + brick.css #193
Comments
|
I intend to offer a 'brick.min' html import that only has one js and one css file, respectively. There is a possibility of converting all the templates to JS and offering a pure JS+CSS, but that would not be something people could easily do a la carte. Documenting and teaching people about best practices re vulcanize and bower is good, but won't help the mortar use case. |
|
In Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1039467 - please close when done? :-) |
|
I did a preliminary exploration with vulcanise but I can't get too far away. I checked all and ran all the bowers and npm installs and stuff, then But... and |
|
OK I found something! Seems like vulcanize is not happy with html imports relative paths including If I copy the component inside the folder (for example as you could do if the dependency was managed with |
|
Hmm, we are using vulcanize with ../ paths in a bunch of places, and it doesn't seem to be exploding. Can I see an example of the code somewhere? |
|
@potch I'm building an example to try to reproduce it with the minimum code! |
|
So for anyone who stumbles upon this, the issues were due to some misconfiguration of Brick generating a |
|
What's the status of HTMLImports in the platform? If they work, then this works as well as one JS, one CSS file, right? If not, then let's figure out what we can do to digest this down to JS/CSS from HTMLImports, for distribution only. Vulcanize's readme says, |
|
Vulcanize generates a js file AND an html file, and that is what the build script is generating right now (see here). The way Brick 2 works, templates are defined and css styles are included using html imports (which are "concatenated" into the html file). This is so styles are scoped and using shadow dom and stuff. Last time I spoke to Potch he was going to look into "processing" the generated html file because it wasn't entirely correct (there were mismatched closing This sort-of-works but
This could be fine in the future when there's support for all of this in Gecko's platform, but that future might be months, or years away. I'm not familiar with the speed of implementing a new API which has a moving spec in Gecko, so I can't foresee how many months/years this is. |
Poking at this issue a little. Unfortunately, Might take a look through how the platform polyfills work, but not sure any of Brick 2 can work without some form of HTML Imports. Maybe we can do something funky that embeds the HTML as strings in JS and somehow hot-wires the HTML import polyfill that way? That seems like a nasty hack though. |
|
That also seems like it'll violate CSP, won't it? |
|
We could generate that JS that has the strings for the templates, and unless I'm overlooking something, I don't think that it would create CSP issues, since we're just creating nodes ( |
|
Good points, sole, thanks |
|
Okay, so I tried an experiment and I'm trying to decide how bad an idea it is. Here are some relevant links:
Rather than vulcanize, I wrote a quick & dirty gulp task to embed HTML in JS for an all-in-one component library. There's also a small hack in the component to use the embedded HTML when available, or to use Basically, this is just a hack around avoiding the use of an HTML Import. |
|
Ohhh coolness! So it's as I was imagining: to implement this in the existing (new) Brick components we'd have to add this sort of "shim" to each component + build script (?). I'm torn as to whether it's worth doing it: a) on one hand it makes the components way easier to distribute because it is just a JS file! Wow yay! Also, edge cases--have you given it a thought about how it could work with recursive html imports? I think this is something vulcanise covers. Your tool should maybe start parsing the html and seeing if there are more imports, and including them into the For example, I wrote a component that used html imports for including another component but this included component was also including stuff using another html import line. If I ran your script over my component I would end up with the first level of imports but not the second so it wouldn't be possible to run it correctly. |
|
So far, I just wanted to see how cumbersome it would be to cram a single HTML "import" into the JS. So, I hadn't really gotten into the full use cases of vulcanize yet And yeah, we'd need to shim every brick component and tweak build scripts. That's not pretty. I'm trying to think through how that might be done more cleanly. Maybe I could hack the polyfills so that But, if this HTML-in-JS thing is not a terrible idea... For recursive component includes, I could concat all the JS together. Then, I could wrap the whole mess with a table of HTML files used by all the JS like this: Also, if this works, I can see whether this could be a patch to vulcanize itself. That could be handy if it got accepted upstream. But, that's getting way ahead of things :) |
|
Spent some time yesterday and today sketching out a vulcanize-esque tool that crams everything into a single JS include. I called it "introvert", because it kind of turns vulcanize inside out. Trying to figure out how to possibly make this just work with existing Brick components. But, as of right now it requires one small tweak to find the I haven't actually tried this out in a browser yet, but the output result looks like this: ;(function () {
function __loadHTML(html) {
var doc = document.implementation.createHTMLDocument('import');
var meta = doc.createElement('meta');
meta.setAttribute('charset', 'utf-8');
doc.head.appendChild(meta);
doc.body.innerHTML = html;
return doc;
}
(function (_ownerDocument) {
(function () {
// x-dep.js
var importDoc;
if (typeof _ownerDocument !== 'undefined') {
importDoc = _ownerDocument;
} else {
var currentScript = document._currentScript || document.currentScript;
importDoc = currentScript.ownerDocument;
}
var template = importDoc.querySelector('template');
/* ... */
});
})(__loadHTML("<!-- x-dep.html -->\n<template>\n <style>/* x-dep.css */\n</style>\n <img src=\"http://www.polymer-project.org/images/logos/p-logo.svg\">\n</template>\n\n\n"));
(function (_ownerDocument) {
(function () {
// x-app.js
var importDoc;
if (typeof _ownerDocument !== 'undefined') {
importDoc = _ownerDocument;
} else {
var currentScript = document._currentScript || document.currentScript;
importDoc = currentScript.ownerDocument;
}
var template = importDoc.querySelector('template');
/* ... */
});
})(__loadHTML("<!-- x-app.html -->\n\n\n<template>\n <style>/* x-app.css */\n</style>\n <x-dep></x-dep>\n</template>\n\n\n"));
})() |
And possibly a version with platform.js and another one without it.
Why? Because I don't want to ship Mortar templates with a dependency that loads a gazillion files on demand. Also because including a .js file + a .css file in a site is so much easier, and we'd hopefully won't be forcing devs to fire up a local server only to check out the template because otherwise weird errors happen (see #192 for reference), and people new to HTML and the web are like
wut?The text was updated successfully, but these errors were encountered: