L’ultimissimo miglioramento che ho in ogni caso poi fatto ad #MBViewer è stato l’aggiunta di una funzione per importare codice #CSS e #JavaScript, per modificare come i post possono essere visualizzati. Entrambi funzionano allo stesso modo, con i relativi parametri URL che accettano sia #URL esterni che data URI. Niente di particolare per gli stili, semplicemente importo nella pagina la qualunque cosa venga data lì, ma per gli #userscripts è stato leggermente più #complicato. 😕️
Il punto sta nel voler evitare che #script essenzialmente non affidabili siano iniettati nel contesto della pagina semplicemente da URL, perché potrebbero fare tante cosine cattive; prima fra tutte, rubare #dati dall’archiviazione del #browser del mio dominio, cosa che è un #problema, perché gli utenti inesperti che aprono la app da #link non andranno a cercare di investigare cosa accade dietro le quinte (e, molto probabilmente, non lo farei realisticamente nemmeno io, seguendo la logica del “i miei siti sono miei e li conosco, sui siti altrui ho le protezioni del browser attive“). E quindi inizio a scendere in un rabbithole… ☠️
#Iframe? Hmm… non so, non è il caso, sarebbero insicuri, ci sono alcuni modi in cui una pagina in frame può fare robe fastidiose. Non può essere assolutamente un’idea, proprio mai (foreshadowing). 🪟️
Trovo un bel po’ di #librerie vecchie che ricompilano codice #JS per rimuovere pericoli, o lo analizzano preventivamente per la presenza di operazioni dannose così che possa non essere mai eseguito… praticamente tutte abbandonate, qualcuna esplicitamente dichiarata insicura e non patchata, e per qualcun’altra lo possiamo dare per scontato. 🐛️
Forse questa libreria più recente, jailed, che sfrutta un iframe assieme ad un Web Worker per creare una sandbox forte e bloccare tutte le #API eccetto alcune che si decidono… No, l’ho provata e non va bene, non si riescono a passare alla sandbox oggetti complessi, tra cui i costruttori, è impossibile far funzionare API tipo quella del DOM. 🚧️
Sarebbe stata un’idea usare qualche reimplementazione del #DOM per NodeJS tramite browserify, tipo Cheerio, ma farla anche solo girare lì dentro è un altro casino allucinante. 🥴️
WASM tecnicamente è una #sandbox a sua volta, e non accede alle API del browser se non con codice colla, quindi magari… teoricamente ok, ma nella pratica non ho trovato nessuna soluzione già bella e pronta che potessi usare per questo specifico scopo. 🕳️
La #pazzia: PyScript… sarebbe quasi già pronto, ma avrei dovuto comunque modificarlo per bloccare tutte le API insicure (rimuovere #codice), e poi richiede 15+ MB di dipendenze di runtime… non ideale. 🗿️
Alla fine ci ho pensato meglio, e sono arrivata alla conclusione che è abbastanza sicuro far girare gli script in un iframe con proprietà src="data:[...]" e sandbox="allow-scripts" (che significa, “blocca tutte le proprietà sensibili eccetto gli script”)… voglio dire, nel visualizzare il contenuto dei siti, già permetto eventuali iframe provenienti dai post, e quelli teoricamente possono già fare quello che vogliono eccetto accedere ai dati della finestra root. Nella pratica, i programmini degli utenti quindi hanno accesso a (quasi) l’intera API JavaScript senza poter fare cose bruttissime. 🎉️
https://octospacc.altervista.org/wp-content/uploads/2024/02/image.pngEcco un esempio di tutto, alla fine: questo URL carica il mio MicroBlog, importa un foglio di #stile che mette questo font buffo, e uno script che colora le parole dei #messaggi in base a come si ripetono man mano (inutile, ma serve giusto per dare idea delle potenzialità)… <a href="https://hub.octt.eu.org/MBViewer/#/siteUrl=https://octospacc.altervista.org|platform=wordpress.org|includeStyle=data:text/css;utf8,@import%20url('https://fonts.googleapis.com/css2?family=Single+Day&display=swap');.MbPost{font-family:'Single%20Day',cursive;}|includeScript=data:text/javascript;utf8,function%20MbViewerFunction(data){const%20dom=new%20DOMParser().parseFromString(data.html,'text/html').body;const%20tokens=dom.textContent.split('%20');const%20words={};for(const%20i%20in%20tokens){const%20word%20=%20tokens[i];if(words[word])words[word]++;else%20words[word]=1;tokens[i]=%60%3Cspan%20style='color:${atob('Iw==')}${[0,'b58900','cb4b16','dc322f','d33682','6c71c4','268bd2','2aa198','859900'][words[word]]};'%3E${word}%3C/span%3E%60}data.html=tokens.join('%20').replaceAll('nn','%3Cbr%3E');for(const%20img%20of%20dom.querySelectorAll('img'))data.html+=img.outerHTML;MbViewerReturn(data)}">https://hub.octt.eu.org/MBViewer/#/siteUrl=https://octospacc.altervista.org|platform=wordpress.org|includeStyle=[...]|includeScript=[...]</a> (il link con tutta quella roba messa inline è una stringa di quasi 1 KB!). Userò tutta la cosa per rendere gli hashtag nel testo meno intrusivi per il mio sito anche lì, oltre che sul dominio originale. 👋️Finisco con dati ancora più tecnici, per chi non ha una vita: con questo #design, ogni #userscript deve provvedere ad esporre una funzione che, tramite la Channel Messaging API, viene richiamata dalla #app per ogni messaggio appena questo viene aggiunto al documento visibile; questa funzione riceve dati utili (per ora, solo l’HTML del contenuto; oltre a dati come l’id del messaggio nel flusso, che non sono granché utili all’utente ma devono essere restituiti alla app) e può rimandare nuovi dati indietro richiamando una funzione che è invece l’applicazione ad esporre allo script. Tutto questo ambaradan permetterebbe agli script di effettuare anche operazioni asincrone, comunque, non per forza di dover agire immediatamente alla chiamata. 🤓️
If you think react is complicated now, go back to 2015 when you had to configure babel and webpack yourself, you had to do SSR and routing yourself, you had to decide between flow and typescript, you had to learn flux and immutable.js, and you had to choose 1 of 100 boilerplates
@yaeunerd Totally agree! The least they could do is make their events system compatible with standard custom events so that WCs could communicate with React Components!
I have the opportunity to do a redesign of a very large site that I built about 5 years ago and have maintained since. Looking to brush up on the newer #CSS / #JS that’s available to me for #frontend. The current site was built with #JQuery and #flexbox was not even an option at the time. Would love to move to #vanillaJS for most things and get the most out of flexbox that I can.
Looking for good resources, if anyone knows of any.
On the JS side there's now lots of vanilla js methods that were influenced by jQuery era libraries so they should feel pretty familiar https://javascript30.com/
I was today years old when I learned about chaining nullish coalescing operators in #javascript as an easy way to check for deep nested properties of an object without having to check each level exists as a separate statement. 🤯
Honestly... it's not exactly anything new that's spurred the realisation that React is overcomplicated for what it tries to do. Glad the light is being found, but yikes that was a long time coming.
"React suggests using a framework to start a project, suggesting to use one of the three main open source frameworks, instead of just React." This itself isn't surprising, as React suffers from the same issues as Framework mania.