Astuces de développement javascript avec symfony


Samuel Breton
Astuces de développement javascript avec...

Dans cet article nous allons voir quelques astuces et bonnes pratiques, non pas directement de développement symfony mais de développement javascript au sein d’un projet symfony.

Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :

  • que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
  • que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel document.write(); ;
  • que l’appel au javascript doit être en bas de page ;

Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.

Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.

(suite…)

Show Comments (6)

Comments

  • Xavier

    Concernant la concaténation des js et CSS en un seul fichier, il est intéressant de regarder d’autres ressources comme par exemple head.js, qui permet un chargement en parrallèle des fichiers d’assets… Avec potentiellement une meilleur performance qu’en chargeant un unique fichier compressé !

    • Article Author
  • NiKo

    Xavier> T’as qu’à dire qu’il pue mon plugin aussi, hein 😉

    Bon OK, head.js est une tuerie. Une solution pragmatique serait de chaîner les chargements asynchrones de fichiers minifiés gérés par head.js. Deal?

    • Article Author
  • Jérémy

    J’ai volontairement choisi de ne pas parler de head.js car même si sur le papier je trouve cette lib excellente, je trouve qu’on manque de retour d’XP sur cette solution. Le fait de charger les JS en asynchrone a forcément un effet bénéfique sur les performances mais à l’heure actuelle est-il possible de le mesurer par rapport à un fichier minifié en cache ?

    Il faudrait également s’assurer de sa comptabilité sur différents navigateurs, enfin surtout IE, pour les autres je ne m’inquiète pas. Je me méfie un peu d’une inclusion massive de JS externe, récemment la lib fancybox bloquait le chargement de toutes les pages pendant 5 secondes sous IE… Ca donne presque envie de développer une modalbox simple, légère et adaptée à ses besoins.
    Bref, je sors du sujet, mais pour conclure je vais suivre de prêt et avec beaucoup d’attention cette émergence de lib de chargement asynchrone, notamment head.js.

    • Article Author
  • Sylvio

    Bonjour,

    Merci pour cet article très intéressant.

    Il y’a beaucoup mieux et beaucoup plus propre que d’utiliser le plugin sfWidgetFormJQueryDate.
    Voir : http://garakkio.altervista.org/datepickerui/
    Un petit script js qui ajoute le datepicker automatiquement aux champs date. Ceci est paramétrable bien sûr. Donc pas de php, on utilise des sfWidgetFormDate de manière classique et du js fait le boulot (donc c’est non intrusif).
    Le script datepicker.js peut par contre être un peu améliorer, de mon coté je l’ai un peu modifié.

    A bientôt peut-être pour l’apéro SF d’Avignon ^^

    • Article Author
  • Sylvio

    Un truc que je comprend pas avec les optimiseurs css/js comme ceux qui sont intégrés dans npAssetsOptimizerPlugin par exemple.

    Pour mes projets SF, je ne fais majoritairement qu’un seul fichier js (main.js) et qu’un seul fichier css (main.css), les autres fichiers inclus étant majoritairement deux des plugins.

    Or en réunissant les fichiers dans un seul (optimized.css / optimized.js), ça fout pas mal de chose en l’air car tous les chemins relatifs des scripts ou css ne fonctionnent plus dès que les fichiers css ou js n’était pas au même niveau que les fichiers optimisés.

    Ce ne serait pas propre de modifier les plugins pour mettre des chemins absolues. J’ai essayé différent optimisateurs, exemple GoogleClosureCompilerAPI me donne de bien meilleurs résultats sur le js mais j’ai toujours des problèmes, surtout sur les css.

    C’est quoi l’astuce ? Car là je comprend pas l’intérêt des ces optimiseurs que j’avais déjà testé auparavant en rencontrant déjà ces problèmes.

    • Article Author
  • ousmane

    Super article ! je comprends mieux pourquoi je galère avec des ‘ $ is not defined ‘ depuis que j’ai utilisé un ‘jq_sortable_element ‘ 🙂

    • Article Author

Recevez nos articles