Logo JavaScript

Mes 6 règles de base pour bien développer avec Ajax

Flattr this!

Aujourd'hui, alors qu'Ajax est devenu est un acteur plus ou moins incontournable du développement web, je me rends compte que certains concepts n'ont pas encore été pleinement saisis par les développeurs eux-mêmes. Voilà mes conseils, mes règles d'or, ce que j'applique à moi-même systématiquement :

Règle #1 : Utiliser un framework reconnu

C'est peut-être bête à dire, le débat framework ou pas framework a déjà été ressassé je ne sais combien de fois mais à moins de maîtriser parfaitement le ou les environnement(s) d'exécution de vos applications web, vous ne pouvez pas vous en passer.

Pourquoi?

Parce que chaque navigateur, même si ça tend à s'amoindrir, implémente de bonnes différences quand à l'interprétation de Javascript. Et c'est encore plus vrai d'une version à l'autre. De plus, réinventer la roue et assurer vous-même la compatibilité, ok, vous allez vous arracher les yeux, gagner le respect de vos collègues pour votre côté suicidaire mais aussi perdre un temps fou.

Utiliser un framework reconnu tel que jQuery, Prototype, Dojo, Mootools ou encore ExtJs, c'est la garantie d'utiliser un truc testé par des milliers de développeurs au quotidien et donc particulièrement fiable. En tout cas à 99% assurément plus fiable qu'un développement perso.

Règle #2 : Utiliser un seul format de discussion client-serveur

Trop souvent, les développeurs se basent sur la flexibilité de Javascript pour faire n'importe quoi. C'est d'autant plus vrai avec les développeurs PHP habitués à un typage dynamique et donc à ne pas faire trop attention à ce genre de choses.

Utiliser un seul format de discussion d'un bout à l'autre de votre application (texte, XML, JSON, ...) vous garantit de toujours savoir ce qui vous sera renvoyé et de ne pas laisser le script se dépatouiller seul. De plus, pour le travail en équipe, les autres développeurs n'auront pas ce point en plus à comprendre.

Règle #3 : Contrôler toutes les requêtes dynamiques

Déléguer une partie du traitement aux clients, c'est bien, ça allège la charge serveur, ça permet d'éviter des aller-retours inutiles vers le serveur et donc soulage la bande passante. Ok, c'est vrai, c'est cool et donc on a envie d'en abuser.

Mais attention, il y a un juste milieu à respecter. Comme toujours, NE JAMAIS FAIRE CONFIANCE AU CLIENT.

L'internaute de base ne connait pas, ne sait pas se servir ou n'a pas d'intention malhonnête concernant votre application, mais on le sait tous (j'espère) qu'il y a toujours un guignol en mal de défis pour tester la sécurité de votre application.

Des données même vérifiées avant envoi par votre script JS sont altérables jusqu'au dernier moment, l'utilisateur peut même court-circuiter vos contrôles. Un minimum de vérifications côté serveur s'impose. Et croyez moi, je la croise souvent cette erreur.

Règle #4 : La session serveur

Le truc bête des applications riches : la perte/fin de session habituellement vous redirige vers votre page de connexion. Pas de bol, un changement d'en-têtes HTTP n'est pas interprétable par Javascript en temps que réponse à un appel asynchrone. Dommage.

Prévoyez toujours ce cas, sinon vos utilisateurs vont juste voir que leurs actions sont sans conséquence et se dire que ça y est, votre application est encore plantée. Ce serait dommage de perdre quelques clients à cause de ce bête problème.

Règle #5 : Gérer les boutons suivant/précédent/rafraîchir

Les erreurs les plus violentes que j'ai vu, les enregistrements mal foutus en base, les logs qui perdent la tête ou les clients insatisfaits, la plupart de ces cas sont souvent dus à une mauvaise gestion (voire aucune) de ces 3 malheureux boutons.

Rappelez-vous toujours que votre page a beau changé autant que vous voulez grâce à tous vos merveilleux scripts, pour le navigateur c'est toujours la même. Un appui malheureux sur F5 et hop, votre application redémarre de 0, perdant tout changement d'états et vos clients perdront parfois leurs cheveux avec.

Règle #6 : Informer l'utilisateur

Cette règle n'est pas dédiée à Javascript mais est encore plus vraie avec. Quand votre script se plante, quand votre serveur ne répond pas (les timeout existent aussi avec les requêtes asynchrones), toutes ses choses sont invisibles pour le client du fait de leur nature. Un petit message bien placé peut éviter bien des questions. Au passage, essayez de faire quelque chose de plus sexy que la pauvre ligne rouge en haut de votre page ou la box alert() habituelle.

Conclusion

Ces conseils ne sont pas transcendants, ce sont l'expression de mon point de vue, de mes pratiques personnelles et ils m'ont aidé dans bien des cas. Et vous? D'autres règles à suggérer? Je suis curieux de vos idées.

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.
  • http://www.mecatrouve.com/ MecaTrouve

    pour la règle 5 « Gérer les boutons suivant/précédent/rafraîchir », il faut utiliser un mécanisme coté serveur genre session ?

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

      La session peut être une solution, mais généralement, il est surtout bon d’empêcher les boutons de provoquer leur comportement par défaut (plus simple). Le souci de cette méthode, c’est que si tu prévois de gérer les boutons du navigateur, faut aussi penser au clavier et aux souris multi-fonctions (entre autres). Le plus simple reste alors souvent de pouvoir toujours déterminer un état en fonction de l’URL. Vu qu’il est possible d’influer avec Javascript sur ce que la barre d’URL contient, autant en profiter.

      Par exemple :
      – tu es sur l’index de ton site : http:// www .tonsite .com
      – via Javascript et ajax, tu affiches la page de présentation d’un produit, tu modifies donc l’URL de ta page en conséquence en modifiant au passage l’historique du navigateur et affiche ainsi : http:// www .tonsite .com/product/1
      – ton client, pas de bol, appuie sur F5. Il rafraîchira cette dernière URL et non le seul domaine de ton site. Côté serveur, si tu as bien géré ton coup, il affichera directement la page du produit. Et si il fait précédent, idem, tu analyses l’URL voulue et affiche la bonne page.

      C’est une façon élégante de gérer ces boutons tout en s’assurant une compatibilité maximale avec les navigateurs. J’ai prévu un billet sur la manipulation de l’historique en JS.

      • http://www.mecatrouve.net MecaTrouve

        merci pour la réponse, j’attends avec impatience ce billet sur la manipulation de l’historique.

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

          Promis, dès que j’ai le temps de l’écrire. J’ai une quinzaine d’articles, 2 tutos pour Developpez et quelques projets en attente… Vivement les vacances pour pouvoir plier tout ça :)

          Mais ça va venir !

Articles liés