~cadence/public-inbox

1

Re: Improving browser compatibility in invidious-redirect

Agustin Ferrari
Details
Message ID
<20200807123037.10897-1-agustinferrari@gmx.com>
DKIM signature
missing
Download raw message
Patch: +34 -12
---
>You haven't supplied the patch here, so I'll reply based on the
>patch that you previously sent to my personal email.
I see, I think it's because I had used the --compose option in git
send-email. Still I include the original patch for reference.
>I'd like to know which browsers specifically you tried this in, because
>I'm not exactly sure which ones are supposed to be supported now that
>weren't before.
I have tested it with Pale Moon 27, Chromium 70 and Firefox 63 and 57
(the latter is from the mobile version).
>- You are still using arrow functions, which are an ES6 feature.
I didn't know that, I always thought it was "syntactic sugar" added
some time before ES6.
>Which browsers support arrow functions but not const?
>- Let is also an ES6 feature. Which browsers support let but not const?
Pale Moon (I don't know if they fixed that in the last version but I
haven't updated it yet because I have some extensions that apparently
stopped working in the most recent version) and the const are supported
but not inside the for loops. So in my previous message also I mentioned
browsers that don't have full support for ECMAScript 6.
You may think that it is a very niche browser to support it, but I
consider that these changes can also benefit smartphone users who may
not have a very modern browser (either because they have not been updated
in a long time or the latest Chrome/Firefox versions do not work well
for them) or those in a similar situation to mine (whether they are
using Pale Moon or are stuck on Firefox 52 ESR or something like that).
Anyway I think that I did not express myself correctly in my last message,
with regard to compatibility I was referring rather to the browsers
of the last 5-7 years (although I have not done tests on older browsers
than the ones I mentioned).
>- You should use XMLHttpRequest in all browsers, instead of maintaining
>two code paths.
I kept fetch because it is supposed to be better than XMLHttpRequest
and I added it as a failback function in case fetch is not available.
>- The for..of loop you created has worse support than the forEach that
>was previously there. for..of syntax is ES6, whereas, I believe,
>NodeList#forEach is ES5.
I could have changed that to a classic for but I did not see it necessary
at that time for what I already explained above.
>- You should abstract XMLHttpRequest into its own function named
>`request` to make the code easier to read.
Neither did I find it necessary to convert it into a new function since
it only runs once.
>indent with tabs and ensure that there is a newline at the end of the file.
I didn't realize, sorry about that.
>why not simply use Babel?
Because it had not occurred to me, I only used Node.js a couple of times
and superficially so I am not familiar with all the possibilities offered
by the language. Anyway I did a quick test at https://babeljs.io/repl
and it is still necessary to change the fetch for something more "backward
compatible". I was going to propose you to add XMLHttpRequest and Babel
in a new patch but I see that you already did it on your own.
---
 src/main.js | 46 ++++++++++++++++++++++++++++++++++------------
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/src/main.js b/src/main.js
index 3a6cf72..eb1b2f2 100644
--- a/src/main.js
+++ b/src/main.js
@@ -3,13 +3,14 @@
;(() => {
	const q = s => document.querySelector(s)
	const qa = s => document.querySelectorAll(s)
	const instancesUrlData = "https://instances.invidio.us/instances.json?sort_by=type,health"

	function createElement(tag, properties = {}, children = []) {
		const e = document.createElement(tag)
		for (const key of Object.keys(properties)) {
		for (let key of Object.keys(properties)) {
			e[key] = properties[key]
		}
		for (const child of children) {
		for (let child of children) {
			e.appendChild(child)
		}
		return e
@@ -23,14 +24,9 @@
		return array
	}

	const destinationPath = window.location.href.slice(window.location.origin.length)

	q("#watch-on-youtube").href = "https://www.youtube.com" + destinationPath

	fetch("https://instances.invidio.us/instances.json?sort_by=type,health").then(res => res.json()).then(
	/** @param {[string, {monitor: any, flag: string, region: string, stats: any, type: string, uri: string}][]} root */ root => {
		shuffle(root)
		root.map(entry => {
	function instanceDataProcessor(data) {
		data = shuffle(data)
		data.map(entry => {
			const healthKnown = !!entry[1].monitor
			return {
				name: entry[0],
@@ -56,6 +52,32 @@
				])
			)
		})
		qa(".loading").forEach(e => e.remove())
	})
		for (let e of qa(".loading")) {
			e.remove()
		}
	}

	const destinationPath = window.location.href.slice(window.location.origin.length)

	q("#watch-on-youtube").href = "https://www.youtube.com" + destinationPath

	try {
		fetch(instancesUrlData).then(res => res.json()).then(jsonData => instanceDataProcessor(jsonData))
	}
	catch(ReferenceError) {
	        // Use XMLHttpRequest when fetch is not available
		const req = new XMLHttpRequest();
		req.open("GET", instancesUrlData, true);
		req.onreadystatechange = function () {
     			if (req.readyState != 4) return;
     			if (req.status != 200 && req.status != 304) {
				//console.log('HTTP error ' + req.status);
				return;
        		}
        		const jsonData = JSON.parse(req.responseText);
			instanceDataProcessor(jsonData);
		}
		req.send()
	}
})()

\ No newline at end of file
--
2.16.4

Re: Improving browser compatibility in invidious-redirect

Details
Message ID
<20200808003739.aa01e50719230693d4150cbe@disroot.org>
In-Reply-To
<20200807123037.10897-1-agustinferrari@gmx.com> (view parent)
DKIM signature
pass
Download raw message
Alrighty, thanks for the detailed reply.

The version with Babel is live on
https://invidious-redirect.cadence.moe . Please try it now with those
browsers you mentioned and see if any further changes are
necessary. I'm just using Babel's preset configuration for IE11, I
have no idea if it's good or not. If it's not good, please let me know
which parts those browsers are having trouble with so that I can find
a configuration that transpiles those specific parts to something
older.

Thanks for your interest in this project!
Export thread (mbox)