mithril.js icon indicating copy to clipboard operation
mithril.js copied to clipboard

I'd like to adjust the outdated banner for the archived pages to be something always up to date.

Open dead-claudia opened this issue 4 years ago • 5 comments

Currently, we have a "deprecated" banner on all v0.2.x stuff. I feel I could easily hack together thing where I could append a quick script to each the archived pages' bodies for a better, more informative, more useful banner. Wouldn't have to be much - I'd just use a couple simple elements to configure:

  • <script src="/static/warn-outdated.js"></script> - This loads the warning label this at the end of the <body>, as a closeable dropdown at the top. It will handle its own styling, too, so I'm not having to add more data to the page than I have to.
  • <meta name="x-mithril-version" content="x.x.x"> - This lets our script know what the current version is, for comparison. x.x.x is the version, where 2.0.4 is for v2.0.4, 0.2.1 is for v0.2.1, and so on. (I would've preferred to use a query parameter on the script, but there's no way I could reliably get the currently executing script element to check that on IE11, and a <meta> element is much easier than the alternatives.)
  • Both elements would be placed in the <head> immediately before the first element other than <meta charset="utf-8">.

Not 100% sure about the design side, but I can get to that later when I get around to implementing this. Do note that the existing deprecation notices in the v0.1/v0.2 docs would also have to disappear.

Script-wise, I could probably get away with something as simple as this:

// This should work on even some of the most ancient of browsers, including IE6.
;(function () {
"use strict";
var meta = document.head.firstChild;
while (meta.tagName !== "meta" && meta.name !== "x-mithril-version") {
	meta = meta.nextSibling;
}
var thisVersion = meta.content;
var domReady = false, xhrReady = false
var xhr = typeof XMLHttpRequest === "undefined"
	? new ActiveXObject("Microsoft.XMLHTTP")
	: new XMLHttpRequest()
var versions

document.onreadystatechange = function () {
	if (document.readyState !== 'interactive') return;
	domReady = true;
	if (xhrReady) next(versions);
};

xhr.onreadystatechange = function () {
	if (xhr.readyState !== 4) return;
	xhrReady = true;
	if (xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) {
		versions = typeof JSON !== "undefined" && JSON.parse
			? JSON.parse(xhr.responseText)
			// The response shouldn't contain any invalid JS characters anyways.
			: eval("(" + xhr.responseText + ")");
	}
	if (domReady) next(versions);
}

// The versions would be stored here.
xhr.open("GET", "/versions.json", true);
xhr.send();

function next(versionsFound) {
	// Create element, style it, and add it
}
})();

Edit: fix a bug in the script loading side

dead-claudia avatar Sep 23 '19 22:09 dead-claudia

@isiahmeadows couldn’t we rather hardcore the version number in a small script that would be generated on release by our npm script?

pygy avatar Dec 16 '19 18:12 pygy

@pygy We could, if you mean something like injecting <script>MITHRIL_VERSION="x.x.x"</script> instead. It functionally works the same way, but it'd save maybe a few dozen bytes if that off the entire page load (not likely to even save a single TCP frame). And besides, we don't have any other critical scripts to load - it's all statically generated HTML.

dead-claudia avatar Dec 19 '19 05:12 dead-claudia

I mean this (but I may be missing your intent).

The latest version is v<span id=mithrilVersion></span>
<script src="latest.js"></script>
// latest.js
mithrilVersion.textContent = "x.y.z"

pygy avatar Dec 23 '19 22:12 pygy

Oh okay. Detecting the latest version was the point of my /versions.json, the file the script would fetch. That file would have an array of versions, something like this (but obviously without the whitespace):

[
	"0.1.3",
	// ...
	"0.2.4",
	"0.2.5",
	"0.2.6",
	// ...
	"1.0.0",
	// ...
	"1.1.7",
	"2.0.0-rc.0",
	// ...
	"2.0.1",
	"2.0.3",
	"2.0.4",
]

Note: broken and unpublished releases like 0.2.3 and 2.0.0 would be intentionally excluded.

I was referring to putting the relative version (like <meta name="x-mithril-version" content="0.2.6">, etc.) in the page's <head> itself, so we can read the version that page's documentation is for.

We can then use that and knowledge of the latest version (as per /versions.json) to decide whether to hide the banner (for the current version), so we can have a dropdown of all the versions where the version you're currently looking at is the one initially selected in the dropdown (like what Python does in their docs).

dead-claudia avatar Dec 26 '19 13:12 dead-claudia

Now this makes complete sense, thanks for clarifying.

pygy avatar Dec 26 '19 21:12 pygy