not for merging: factor out navigation tree - different options

[epaulson]

This is really more of an issue but I wanted to include a quick code example.

Anyway, a big challenge right now is the output of make-site includes a full copy of the nav tree in every html file, which means that the resulting static site is huge - if you add Brick.ttl to the site and generate a site, you get 2.5 gigs of HTML. With this change it's cut down to 110 megs - still a lot, but not nearly as painful. (For reference, the current brick website is probably in the 60-ish meg size for a single version, it's a little hard to account for because it's spread out over a bunch of files in multiple parts of the tree and some JSON)

The code is straightforward, and basically copied from stackoverflow (https://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file ) - in make-site, we dump out a tree as a fragment, and then at runtime jquery loads it and slips it into the DOM.

(Note that this pull request is incomplete - you need to actually add the jquery code. I tried added it to the main.ts in explorer-site/src/main.ts but the '$' introduced a whole slug of typescript errors on when running 'npm run build' for the tools around missing definitions for HTML elements- I tried for a while to add the right jquery typescript types but gave up, deleted my node_modules and started over - so after doing an 'npx rdf make site', I just replace public/site.min.js with the following file:

"use strict";(()=>{window.onclick=function(e){let t=e.target;for(;t instanceof Element;){if(t.tagName==="A"){let n=t.getAttribute("data-href");t.getAttribute("rel")||(e.preventDefault(),n&&(window.location.href=n));break}t=t.parentElement}}})();

$(function(){
      $("#nav").load("/navfragment.html"); 
    });

)

So this is one option that gets us part of the way there.

I think the main things that we'd like:

• Remove redundant content from every page to keep size down
• Support direct linking, e.g. copying a link into a chat window and giving it to someone else like say http://localhost:8000/brick/Boiler_Command should give us that page directly
• still be completely static-hostable
• keep the nav tree state open to the same spot/state when clicking on a new class

The jquery setup does the first 3 OK, but doesn't help us directly on the 4th.

On the 4th one, I don't think it'd be too hard to have the nav tree expand to the selected class when the page is opened. However, the tree right now can have multiple subtrees expanded and we wouldn't be able to do that without something keeping state or else simulating a page load without actually causing a full new page load.
(The current brickschema.org ontology browser opens the tree only to the current class but doesn't keep anything else in the tree expanded if anyone is clicking around and goes to the new class - if you're browsing in points and then open up equipment and click on VAV, when the VAV page loads the points tree is closed again)

We could try an iframe - I tried one for about 2 minutes and it's included in the PR though I think I'm doing it backwards, and I didn't even try to get the CSS to match and the javascript attached, but it might be the easiest way forward.

We could also go all-in and use something like vue.js and use the vue router (or react or angular or whatever) which can handle all of the client side work to keep the state of the nav tree stable while swapping out content, and keeping the URL history correct. Since we're generating a page for each thing I think we can still keep the static hosting reasonably OK, and I am hopeful that Google et al run enough of the javascript so someone could get a link to brickschema.org/ontology/brick/VAV.html if a searcher wanted to find the definitions directly.

I guess I'm maybe fine with jquery and maybe creating a sitemap file so the search engines can find all of the subpages?

@jbkoh @gtfierro

[ektrah]

Thanks a lot for sharing!

I would add three more things we'd like:

• If you scroll down a page, click a link, and then use the back button to go back, the first page should still be in the state it was (scrolled down).
• The individual pages should be indexable for search engines and valid entry points for site visitors.
• The site should not be completely unusable on a smartphone.

Here's a little experiment I did a while ago that ticks some boxes: experiment.zip. The idea was to have a main page containing the navigation and an iframe where the individual pages are loaded. With a little JavaScript, the URL of the main page is updated in the address bar every time you navigate within the iframe. (The experiment must be served from an HTTP server for everything to work.)

[epaulson]

Neat. I'm a little hesitant on iframes but for a dumb reason - iframes for sidebar navigation have fallen out of favor though I just don't do enough front-end work to really be able to tell if there are still good use cases like this one to justify them.

Easy enough to change later, I suppose!