S(GH)PA: l'hack dell'app a pagina singola per le pagine GitHub

Da tempo desideravo la possibilità di instradare i percorsi di un sito Web GitHub Pages al suo index.html per la gestione come app a pagina singola (SPA). Si tratta di table-stakes perché tali app richiedono che tutte le richieste vengano instradate a un file HTML, a meno che tu non voglia copiare lo stesso file su tutti i tuoi percorsi ogni volta che apporti una modifica al progetto. Attualmente, GitHub Pages non offre una soluzione di gestione del percorso; il sistema Pages vuole essere un meccanismo semplice e piatto per servire il contenuto di base del progetto.

Nel caso non ne fossi a conoscenza, GitHub fornisce un pezzetto di personalizzazione per il sito Web del tuo progetto: la possibilità di aggiungere un file 404.html e farlo servire come pagina di errore personalizzata. Ho fatto un primo tentativo con un hack SPA semplicemente duplicando il mio file index.html e rinominando la copia in 404.html . Si scopre che molte persone hanno riscontrato lo stesso problema con le pagine GitHub e hanno apprezzato l'idea generale. Tuttavia, il problema che alcune persone su Twitter hanno sollevato correttamente è che la pagina 404.html è ancora servita con un codice di stato 404, che non va bene per i crawler dei motori di ricerca. Il guanto di sfida era stato lanciato e ho deciso di rispondere... e di rispondere con vigore!

Ancora una volta con sentimento

Dopo aver dormito su di esso, ho pensato tra me e me: "Se stesso, siamo nel profondo del territorio di un hackeraggio sporco, quindi perché non lo rendo ancora più sporco?!" A tal fine, ho sviluppato un hack ancora migliore che fornisce la stessa funzionalità e semplicità, preservando allo stesso tempo il succo del crawler del tuo sito Web e non devi nemmeno perdere tempo a duplicare il tuo file index.html e rinominarlo in 404.html più ! La seguente soluzione dovrebbe funzionare in tutti i moderni browser desktop e mobili (Edge, Chrome, Firefox, Safari) e in Internet Explorer 10+.

Modello e demo : se vuoi saltare la spiegazione e ottenere la merce, ecco un repository modello e un URL di prova per vederlo in azione.

È così Meta

La prima cosa che ho fatto è stata esaminare altre opzioni per far reindirizzare il browser alla pagina index.html . Quella parte è stata piuttosto semplice. Fondamentalmente hai tre opzioni: una configurazione del server, una manipolazione della location JavaScript o un meta tag di refresh . Il primo è ovviamente un divieto per le pagine GitHub. E JavaScript è fondamentalmente lo stesso di un aggiornamento, ma probabilmente peggio per l'indicizzazione del crawler. Questo ci lascia con il meta tag. Un meta tag con un valore di aggiornamento di 0 sembra essere trattato come un reindirizzamento 301 dai motori di ricerca, il che funziona bene per questo caso d'uso.

Dovrai iniziare aggiungendo un file 404.html a un repository gh-pages che contiene un documento HTML vuoto al suo interno. Quel documento deve avere un totale di più di 512 byte (spiegato di seguito). Quindi, inserisci il seguente markup nell'elemento head della tua pagina 404.html :

 <script> sessionStorage.redirect = location.href; </script> <meta http-equiv="refresh" content="0;URL='/REPO_NAME_HERE'">

Questo codice imposta l'URL del tentativo di ingresso su una variabile nell'oggetto sessionStorage standard e reindirizza immediatamente alla pagina index.html del progetto utilizzando un meta tag di aggiornamento. Se stai creando un sito dell'organizzazione Github, non inserire un nome repository nel testo sostitutivo dell'attributo del contenuto, fai semplicemente questo: content=“0;URL='/'”

Personalizzazione della gestione del percorso

Se desideri una gestione del percorso più elaborata, includi semplicemente una logica JavaScript aggiuntiva nel tag di script mostrato sopra. Puoi modificare diverse cose: la composizione href che passi alla pagina index.html ; quali pagine devono rimanere nella pagina 404 (tramite rimozione dinamica del meta tag); e qualsiasi altra logica che desideri mettere in atto per dettare quale contenuto viene mostrato in base al percorso in entrata.

512 byte magici

Questa è, senza dubbio, una delle stranezze più strane che abbia mai incontrato nello sviluppo web. Devi assicurarti che la dimensione totale della tua pagina 404.html sia maggiore di 512 byte, perché in caso contrario, Internet Explorer la ignorerà e mostrerà invece una pagina 404 generica del browser. Quando finalmente l'ho capito, ho dovuto aprire una birra per far fronte alla quantità di tempo che ci voleva.

Facciamo Storia

Per acquisire e ripristinare l'URL a cui l'utente ha navigato inizialmente, devi aggiungere il seguente tag di script head della tua pagina index.html prima che qualsiasi altro JavaScript agisca sullo stato corrente della pagina:

 <script> (function(){ var redirect = sessionStorage.redirect; delete sessionStorage.redirect; if (redirect && redirect != location.href) { history.replaceState(null, null, redirect); } })(); </script>

Questo bit di JavaScript recupera l'URL che abbiamo memorizzato nella cache in sessionStorage sulla pagina 404.html e sostituisce la voce della history corrente con esso. Il modo in cui scegli di gestire le cose da qui dipende da te, ma se fossi in te userei popstate e hashchange .

Bene, gente, questo è tutto. Ora festeggia scrivendo alcune app a pagina singola su GitHub Pages!

Questo articolo fa parte di una serie di sviluppo Web di esperti e ingegneri della tecnologia Microsoft sull'apprendimento pratico di JavaScript, sui progetti open source e sulle best practice per l'interoperabilità, incluso il browser Microsoft Edge.

Ti invitiamo a eseguire test su browser e dispositivi (incluso Microsoft Edge, il browser predefinito per Windows 10) con strumenti gratuiti su dev.microsoftedge.com, inclusi gli strumenti per sviluppatori F12: sette strumenti distinti e completamente documentati per aiutarti a eseguire il debug, il test e velocizza le tue pagine web Inoltre, visita il blog di Edge per rimanere informato da sviluppatori ed esperti Microsoft.

Ulteriori letture su SmashingMag:

• Un semplice flusso di lavoro dallo sviluppo alla distribuzione
• Creazione di un'app Web completa in Foundation for Apps
• Crea un blog con le pagine di Jekyll e GitHub