How shall we deploy JS and HTML for Jekyll site?
sammyjava opened this issue · comments
I'd like to figure this out, or have someone else figure it out. We talked about using a submodule to deploy "shims" so that we don't have to copy code to jekyll-legumeinfo from web-components. So one thought is that we roll what is now in /dev into /dist and have /dist become a submodule (which is built by npm as normal):
shokin@morangie:~/web-components$ ls dist-as-submodule/
controllers index.js lis-linkout-element.d.ts lis-publication-search-element.js lis-trait-search-element.d.ts README.md
core index.js.map lis-linkout-element.d.ts.map lis-publication-search-element.js.map lis-trait-search-element.d.ts.map web-components.bundled.js
graphql.js lis-gene-search-element.d.ts lis-linkout-element.js lis-qtl-search-element.d.ts lis-trait-search-element.js
html lis-gene-search-element.d.ts.map lis-linkout-element.js.map lis-qtl-search-element.d.ts.map lis-trait-search-element.js.map
index.d.ts lis-gene-search-element.js lis-publication-search-element.d.ts lis-qtl-search-element.js mixins
index.d.ts.map lis-gene-search-element.js.map lis-publication-search-element.d.ts.map lis-qtl-search-element.js.map models
shokin@morangie:~/web-components$ ls dist-as-submodule/html
core examples lis-gene-search-element.html lis-linkout-element.html lis-publication-search-element.html lis-qtl-search-element.html lis-trait-search-element.html
I know we only need web-components.bundled.js and graphql.js, but I don't think it's horrible to take those other files along for the ride, they're not huge. And then you see I've put dev/* into what would be dist/html.
This make any sense? Then we use web-components-dist in jekyll-legumeinfo with includes or symlinks.
We had a discussion about this at the stand-up this morning and thought it makes sense for the code in the dev/ directory to be separate from the Jekyll sites. The reasons being that it's intended for testing the web components and may not align well with the production use cases, and it may get "ahead" of the Jekyll sites (i.e. breaking changes) since web component development precedes Jekyll development.
The solution we discussed is to just add the code to the Jekyll sites (ideally via the Jekyll theme and starter) in the assets/js/ directory and in the templates and pages. The web-components.bundled.js file would also be included in this way, which would ensure that the code aligns with the included version. Thoughts?
Sounds fine to me. I was thinking we'd avoid "getting ahead" via merges to web-components:main (designated as ONLY production) but copying stuff over to Jekyll's dirs is fine by me. Not a major issue. I'll rearrange the current gene-search branch of jekyll-legumeinfo the way you describe for a look-see.
Okay, same topic, did you want me to put the Javascript that's currently in gene-search.html into JS files under assets? There are constants and functions:
const geneFormDataQuery
const geneQuery
const geneLinkoutsQuery
const locationLinkoutsQuery
const geneSearchElement = document.getElementById('gene-search');
const linkoutElement = document.getElementById('linkouts');
function getGeneFormData({abortSignal}) {
function getGenes(searchData, page, {abortSignal}) {
function linkoutFunction({type, variables}, {abortSignal}) {Leaving only
---
layout: default
title: Gene Search
---
<script type="text/javascript" src="/assets/js/graphql.js"></script>
<script type="module" src="/assets/js/web-components.bundled.js"></script>
<div class="uk-container">
<!-- the custom gene search element -->
<lis-gene-search-element id="gene-search"></lis-gene-search-element>
<lis-modal-element modalId="modal">
<lis-linkout-element id="linkouts"></lis-linkout-element>
</lis-modal-element>
</div> window.onload = (event) => {
...
};Or maybe we'd want to leave
const geneSearchElement = document.getElementById('gene-search');
const linkoutElement = document.getElementById('linkouts');in gene-search.html as well, since it refers to the current document.
I would say put things like
const geneFormDataQuery
const geneQuery
const geneLinkoutsQuery
const locationLinkoutsQuery
function getGeneFormData({abortSignal}) {
function getGenes(searchData, page, {abortSignal}) {
function linkoutFunction({type, variables}, {abortSignal}) {In their own respective JS files, and put component-specific things like
window.onload = (event) => {
...
};
const geneSearchElement = document.getElementById('gene-search');
const linkoutElement = document.getElementById('linkouts');in the HTML with their respective components.
Moved to jekyll-legumeinfo. Check out the gene-search branch layout: /assets/js and /tools/search. I went totally minimal on the JS files, maybe overboard.
Looks pretty good. A couple thoughts on the assets/ directory:
- It may be worth adding some sub-directories to assets/js/ to keep things more organized, e.g. webcomponents/, graphql/, and uikit/.
- I think it makes sense to put the graphql queries in the same files as the functions that use them. This will reduce the numbers of files and imports.
- Assuming all the graphql files have been added to their own sub-directory, you could add an index.js file to that directory, which would allow everything to be imported through that one file in the templates (see the HTML files in the dist/ directory of the web-components repo for an example).
I've done the first two. I'm not sure we want to just automatically import any graphql Javascript files from an index file, when any particular component will only use a few of them. For example, gene search uses get-genes.js and get-gene-form-data.js, but QTL or any other search won't. And there could get to be quite a few different graphql functions used by the web components.
The only JS that I see ALL components including is graphql.js. Even linkout-function.js is specific to things that have linkouts written for them.
Yeah, it's a trade-off for sure: convenience vs page bloat. You could make the same argument for the web components themselves; why bundle them all together into a single web-components.bundled.js file when no page in our site is going to use more than a few at the same time?
I would totally not bundle them together, but I get that that's how things tend to be done with node apps. Everyone is assumed to be on 10 Mbps lines these days with browsers and computers that can handle massive amounts of code in huge RAM. Which I find irresponsible, but that's how the big companies have progressed.
not %100 sure but I think at least some of the bundlers support lazy loading (ie relevant chunks get loaded when there is actual demand for the functionality that they represent). Not that there isn't still ample room to complain about the cash value of caching...
Yeah, our web component bundling isn't that sophisticated. And no worries about using an index.js file for the graphql shims. It was just a suggestion.
I think this issue is closeable.