S(GH)PA : le hack d'application monopage pour les pages GitHub

Depuis un certain temps, je voulais avoir la possibilité d'acheminer les chemins d'un site Web GitHub Pages vers son index.html pour le gérer comme une application monopage (SPA). Il s'agit d'enjeux de table, car de telles applications nécessitent que toutes les demandes soient acheminées vers un seul fichier HTML, à moins que vous ne souhaitiez copier le même fichier sur tous vos itinéraires chaque fois que vous apportez une modification au projet. Actuellement, GitHub Pages n'offre pas de solution de gestion d'itinéraire ; le système Pages est destiné à être un mécanisme plat et simple pour servir le contenu de base du projet.

Au cas où vous ne le sauriez pas, GitHub fournit un morceau de personnalisation pour le site Web de votre projet : la possibilité d'ajouter un fichier 404.html et de le faire servir de page d'erreur personnalisée. J'ai pris un premier coup de piratage SPA simplement en dupliquant mon fichier index.html et en renommant la copie en 404.html . Il s'avère que de nombreuses personnes ont rencontré le même problème avec les pages GitHub et ont aimé l'idée générale. Cependant, le problème que certaines personnes sur Twitter ont correctement soulevé était que la page 404.html est toujours servie avec un code d'état de 404, ce qui n'est pas bon pour les robots des moteurs de recherche. Le gant était tombé, et je décidai de répondre — et de répondre avec vigueur !

Une fois de plus, avec émotion

Après avoir dormi dessus, je me suis dit: "Moi, nous sommes profondément en territoire de piratage sale, alors pourquoi ne rendrais-je pas ce piratage encore plus sale ?!" À cette fin, j'ai développé un hack encore meilleur qui offre la même fonctionnalité et la même simplicité, tout en préservant le jus du robot d'exploration de votre site Web - et vous n'avez même plus besoin de perdre du temps à dupliquer votre fichier index.html et à le renommer en 404.html . ! La solution suivante devrait fonctionner dans tous les navigateurs de bureau et mobiles modernes (Edge, Chrome, Firefox, Safari) et dans Internet Explorer 10+.

Modèle et démo : si vous souhaitez ignorer l'explication et obtenir les marchandises, voici un référentiel de modèle et une URL de test pour le voir en action.

C'est tellement méta

La première chose que j'ai faite a été d'étudier d'autres options pour que le navigateur redirige vers la page index.html . Cette partie était assez simple. Vous avez essentiellement trois options : une configuration de serveur, une manipulation d' location JavaScript ou une balise méta d' refresh . Le premier est évidemment interdit pour les pages GitHub. Et JavaScript est fondamentalement identique à une actualisation, mais sans doute pire pour l'indexation des robots. Cela nous laisse avec la balise meta. Une balise meta avec une valeur d'actualisation de 0 semble être traitée comme une redirection 301 par les moteurs de recherche, ce qui fonctionne bien pour ce cas d'utilisation.

Vous devrez commencer par ajouter un fichier 404.html à un référentiel gh-pages contenant un document HTML vide à l'intérieur. Ce document doit totaliser plus de 512 octets (expliqué ci-dessous). Ensuite, placez le balisage suivant dans l'élément head de votre page 404.html :

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

Ce code définit l'URL d'entrée tentée sur une variable de l'objet standard sessionStorage et redirige immédiatement vers la page index.html de votre projet à l'aide d'une balise meta refresh. Si vous créez un site d'organisation Github, ne mettez pas de nom de dépôt dans le texte de remplacement de l'attribut de contenu, faites simplement ceci : content=“0;URL='/'”

Personnalisation de la gestion des itinéraires

Si vous souhaitez une gestion de route plus élaborée, incluez simplement une logique JavaScript supplémentaire dans la balise de script ci-dessus. Vous pouvez modifier plusieurs choses : la composition du href que vous transmettez à la page index.html ; quelles pages doivent rester sur la page 404 (via la suppression dynamique de la balise meta) ; et toute autre logique que vous souhaitez mettre en place pour dicter le contenu affiché en fonction de la route entrante.

512 octets magiques

C'est, de loin, l'une des bizarreries les plus étranges que j'ai jamais rencontrées dans le développement Web. Vous devez vous assurer que la taille totale de votre page 404.html est supérieure à 512 octets, car si ce n'est pas le cas, Internet Explorer l'ignorera et affichera une page 404 de navigateur générique à la place. Quand j'ai finalement compris cela, j'ai dû ouvrir une bière pour faire face au temps que cela prenait.

Faisons l'histoire

Pour capturer et restaurer l'URL vers laquelle l'utilisateur a initialement navigué, vous devez ajouter la balise de script suivante à l'en- head de votre page index.html avant que tout autre code JavaScript n'agisse sur l'état actuel de la page :

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

Ce morceau de JavaScript récupère l'URL que nous avons mise en cache dans sessionStorage sur la page 404.html et remplace l'entrée d' history actuelle par celle-ci. La façon dont vous choisissez de gérer les choses à partir d'ici dépend de vous, mais j'utiliserais popstate et hashchange si j'étais vous.

Eh bien, les amis, c'est tout. Maintenant, allez célébrer en écrivant des applications d'une seule page sur les pages GitHub !

Cet article fait partie d'une série de développement Web rédigée par des évangélistes et des ingénieurs de la technologie Microsoft sur l'apprentissage pratique de JavaScript, les projets open source et les meilleures pratiques d'interopérabilité, y compris le navigateur Microsoft Edge.

Nous vous encourageons à effectuer des tests sur tous les navigateurs et appareils (y compris Microsoft Edge, le navigateur par défaut de Windows 10) avec des outils gratuits sur dev.microsoftedge.com, y compris les outils de développement F12 : sept outils distincts et entièrement documentés pour vous aider à déboguer, tester et accélérer vos pages Web. Visitez également le blog Edge pour rester informé par les développeurs et experts Microsoft.

Lectures complémentaires sur SmashingMag :

• Un workflow simple du développement au déploiement
• Création d'une application Web complète dans Foundation for Apps
• Créer un blog avec des pages Jekyll et GitHub