Logo JavaScript

Historique applicatif avec JavaScript

flattr this!

Je travaille actuellement sur une application riche (RIA) entièrement codée en JS. Et il me semble important d'éclaircir un point clé : l'historique applicatif.

Un peu d'histoire

Dans le "web 1.x", quand les sites étaient des pages qui s'enchaînaient, on pouvait se permettre de ne pas s'en préoccuper puisque l'historique navigateur était naturellement rempli par tout chargement de page. Vous pouviez donc savoir par où vous étiez passés et y revenir.

L'arrivée d'Ajax, le début du grand LOL

Et d'un seul coup est arrivé Ajax. On pouvait charger notre application puis ne plus charger que les données. Je ne vais pas critiquer, c'est cette avancée qui a donné à JS ces lettres de noblesse et m'a permis de faire un métier que j'aime. Par contre, j'ai quand même bien rigolé. Plutôt jaune mais rigolé quand même.

Vous vous souvenez de cette phrase culte qu'on a plus ou moins tous utilisé :

Il ne faut pas toucher à Précédent/Suivant et Rafraichir sinon tu risques de tout perdre.

Euh ???

Cette phrase est très expressive sur ce qui va suivre. Sur le principe, ça n'a l'air d'avoir pas dérangé grand monde de se dire que le comportement même de l'application allait à l'encontre du fonctionnement naturel de tout navigateur. Et comble de tout ça, en plus, on engueulait nos utilisateurs en leur disant de ne pas faire quelque chose qui leur est naturel. Autant demander à un animal affamé de ne pas manger avec une gamelle de bouffe à dispo. C'est débile, ridicule et si l'animal a des dents, ça peut être dangereux.

L'actualité

Soyez en surpris ou non, mais 90% des applications "riches" encore développées aujourd'hui continue d'être à côté de leurs pompes et de faire de la merde dans ce genre. Il suffit d'aller sur Developpez.com, Codes-Sources, Code-Project, Stackoverflow ou même Twitter. Le nombre de sujets/messages à propos de comment bloquer le clic-droit ou les boutons natifs du navigateur sont incalculables et il y en a de nouveaux tous les jours. Il y a même régulièrement des plugins jQuery qui sortent pour faire ça (lol).

La solution

Faites votre boulot. Tout simplement. Quasiment tous les développeurs JS connaissent cette ligne de script :

window.history.go(-1);

Eh les mecs, soyez intelligents, si il existe un objet history et même une méthode go qui prend un paramètre numérique négatif pour aller en arrière, c'est sûrement qu'on peut faire d'autres trucs. Non ?

Aller en avant

Truc super balaise de fous :

window.history.go(1);

Et encore, on aurait pu faire ça :

window.history.forward();

L'équivalent arrière, c'était ça :

window.history.back();

Gestion de l'historique

Bon on arrête de jouer et on fait des trucs utiles. Vous changez le contenu de votre page dynamiquement. Jusque là votre utilisateur était sur la page d'entrée de votre site. Pas de problème, l'URL peut être :

http://www.votre-site.fr/

Et là vous ouvrez une popin de connexion pour un espace privé. Avant vous auriez été sur cette page (ou assimilable) :

http://www.votre-site.fr/connexion

Et pourquoi plus maintenant ? Parce qu'Ajax charge les données sans recharger la page ? C'est ça votre excuse ? Faites une ligne de code de plus dans les callbacks de vos chargements Ajax pour avoir l'air un million de fois plus intelligent que vos congénères :

window.history.pushState({}, "Connexion", "connexion");

Wooaaahhh ! Regardez l'URL, sans avoir rechargé la page, vous êtes pourtant maintenant sur

http://www.votre-site.fr/connexion

Et en plus dans l'historique du navigateur, vous avez une nouvelle entrée. Vous avez votre application dynamique, vous ne rechargez pas la page et vous n'avez plus besoin de sortir des infamies à vos clients.

Je vous laisse farfouiller dans les détails de la doc fournie par Mozilla. Pas la meilleure mais qui a pour mérite d'exister.

Reste ensuite à vous d'attraper les évènements comme ils viennent avec la méthode popState() pour réagir. Et à faire en sorte que votre serveur soit capable de renvoyer l'appli proprement avec la popin de connexion ouverte si votre utilisateur vient directement avec l'URL de connexion.

flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • Nico

    Je me coucherais moins con! Merci Math ;)

    • http://www.mathieurobin.com/ Mathieu

      Tant qu’à rendre service ;)

  • http://fabienzibi.com/ faz

    101% d’accord avec toi, et merci pour la doc, tant qu’à faire, autant coder proprement ;)

    • http://www.mathieurobin.com/ Mathieu

      C’est carrément au dessus de la simple qualité de code, c’est de la conception. Sans parler de l’impact sur le SEO par exemple

  • waqueteu

    Bizarre, le jour ou je découvre et utilise pour la première fois dans mes pages les outils window.history, tu en parles dans sur ton blog et répond à quelques questions que je me posais.
    En tout cas merci, c’est juste ce dont j’avais besoin.

    • http://www.mathieurobin.com/ Mathieu

      Content de tomber à pic alors ;)

  • rohk

    Merci pour ce post. Attention quand même, pushState est une feature HTML5 et n’est donc pas supporté par tous les navigateurs. Pensez donc à utiliser un polyfill genre History.js. Et plutôt que de gérer ça à la mano via window.history.pushState(), utiliser une librairie genre Hasher.js. :)

    • rohk

      EDIT : En réalité Hasher.js utilise des hash et non pas pushState. Le fonctionnement est différent.

    • http://www.mathieurobin.com/ Mathieu

      Je considère que si tu développes une appli RIA, tu peux délaisser l’idée de la compatibilité sur les vieux navigateurs. Enfin en général, c’est loin d’être ma première préoccupation. Après j’ai l’avantage de ne pas travailler sur du grand public et donc de me permettre de suggérer à mes visiteurs de changer de navigateurs.

  • check_ca

    Merci pour cet article qui rappelle les bases :)

    Petite question à 2 sous qui n’a pas de rapport direct avec le sujet traité : l’application riche que tu développes est-elle destinée à publier des infos publiques et réferençables par les moteurs de recherche ? Si oui, comment est gérée cette problématique ?

    • http://www.mathieurobin.com/ Mathieu

      Partiellement. En gros, vu que tu peux changer l’URL pour gérer les suivant/précédent/rafraîchir, ton serveur peut/doit aussi savoir renvoyer la page que tu accèdes après 3 clics ou un seul. C’est ce que beaucoup de sites appellent le « permalien ». A partir du moment où ceci est effectif, tu peux te faire référencer via des backlinks et donc oui, apparaître dans les moteurs de recherche. Concernant l’indexation naturelle, Google sait remonter une bonne partie du JS (je crois), et ils ne sont pas les seuls.

      • check_ca

        Merci pour cette réponse. En fait, je suis en train de travailler sur un service de snapshot qui permettrait de servir à Google (et autres) les pages générées dynamiquement (i.e. via des appels Ajax) pour faciliter le référencement. Google sait partiellemnt trouver des contenus générés dynamiquement mais leur comm’ à ce sujet n’est pas claire du tout et surtout la plupart du temps, ca ne marche pas. Ce service (dans le cloud) aura l’avantage de n’imposer aucune contrainte sur les technos utiliséés pour developper la RIA et rendra le référencement 100% fiable. Si ca t’interesses, tu peux me joindre par mail pour en parler d’avantage.

        • check_ca

          En fait, pour être plsu clair, on cherche des beta testeurs ;)

          • http://www.mathieurobin.com/ Mathieu

            Je suis encore loin de pouvoir dire que mon appli est prête pour servir de cobaye. Et justement, j’ai fait mon maximum pour que la partie dynamique ne soit pas un frein pour le référencement. Je me suis rarement aussi déchaîné pour une architecture. J’en reparlerai quand elle sera un peu plus éprouvée.

  • https://twitter.com/cjean Christophe Jean

    Il faut noter toutefois que l’API history n’est pas disponible sur tous les navigateurs. Dans ce cas là, un fail back avec un système de hash dans l’url (http://www.votre-site.fr/#connexion) peut être satisfaisant (même si il faudra du coup, vérifier la valeur lors du chargement pour charger les ressources correspondantes en ajax plutôt que directement dans le contenu de la page)

    • http://www.mathieurobin.com/ Mathieu

      Oui on est d’accord

Articles liés