Bonjour,
Vous ne vous êtes jamais retrouvé avec un script impossible à déboguer parce qu'il avait été chargé en Ajax ?
Si oui, je vous propose cet article qui vous guidera pour déboguer ce script grâce à l'utilisation du plugin jQuery.loadScript :
:fleche: Chargez en Ajax des fichiers scripts déboguables
N'hésitez pas à faire part de vos remarques et surtout, bon code !
Marc
Bonjour,
Je viens de faire une petite correction dans l'article car je viens de m'apercevoir que depuis la version 1.5 de jQuery, le fonction jQuery.getScript retourne un objet jQuery.Deferred alors que j'étais persuadé du contraire...
Excusez-moi pour cette petite coquille :?
Marc
Bonjour,
Je ne suis pas sûr de comprendre, en quoi charger un script en AJAX le rend difficile à déboguer ? Avec l'inspecteur Webkit, il apparaît dans les ressources et on peut utiliser breakpoints et autres outils de la même façon que s'il était chargé via une balise <script>.
Aussi, pouvez-vous préciser qu'est-ce qu'apporte $.loadScript en comparaison avec $.getScript ? Ce n'est pas très explicite dans l'article, tout ce que j'ai retenu est que le success callback est appelé sans arguments.
Bonjour SylvainPV,
La fonction $.getScript de jQuery charge les scripts de manières différentes si le script est local (sur la même machine que la page HTML) ou si le script est distant.
Autant lorsque le script est distant, il est déboguable au même titre que les fichiers chargés depuis une balise script, par contre lorsque celui-ci est local, jQuery utilise Ajax pour le charger ce qui le rend illisible pour les débogueur car tout le code s'affiche sur une seule ligne.
C'est dans ce cas que $.loadScript devient intéressant ;)
Je n'ai jamais observé ce comportement. Charger en AJAX ne change pas la source, qui devrait donc s'afficher de la même façon. Êtes-vous sûr que cela ne provient pas de votre debugger ou d'une mauvaise configuration de votre serveur qui minimise automatiquement les scripts ?Citation:
Envoyé par marcbuils
J'ai réalisé un test avec un script local chargé avec jQuery.getScript, la source m’apparaît bien formatée :
http://i.imgur.com/1lBHH.png
C'est étonnant, je n'ai pas du tout le même comportement.
Sur le débogueur de Chrome, le script chargé par l'intermédiaire de $.getScript n'apparait même pas alors qu'il est correctement exécuté. Et c'est un problème que je rencontre, moi mais aussi d'autres personnes avec qui j'en ai parlé, depuis des années et sur de nombreux serveurs différents.
Voici un aperçu:
http://i.imgur.com/ZiqBt.png
SylvainPV, en regardant de plus près ton aperçu d'écran, je me suis redu compte que l'onglet que tu présentes est l'onglet "Network", ce qui signifie que tu vois bien le fichier être appelé en Ajax.Citation:
Envoyé par SylvainPV
Par contre Chrome ne te permet pas de placer des points d'arrêts dans ton code ou encore espionner la valeur des variables.
C'est ce genre de choses que te permet de faire la fonction $.loadScript.
D'accord, je comprends mieux. J'ai retrouvé le problème ici :
http://stackoverflow.com/questions/6...cript-function
Les scripts en local chargés via $.getScript sont ajoutés en inline et non en référence externe. J'ignore la raison, et je n'ai pas vu de réponse de l'équipe jQuery à ce sujet.
Aussi, j'ai trouvé un gist assez court qui corrige ce problème sur la fonction $.getScript d'origine. Ca serait intéressant de comparer vos implémentations :
https://gist.github.com/896561
Je viens de regarder le code en question et on utilise en fait exactement le même principe.Citation:
Envoyé par SylvainPV
A savoir qu'on ajoute simplement une balise "script" dans la balise "head" du HTML, avec le champs src qui pointe vers le fichiers à charger.
La fonction $.loadScript est juste un peu plus complète puisqu'elle retourne un objet deferred qui permet de synchroniser plusieurs appels simultanés.
Exemple:
Pour information, le fichier script compressé pèse seulement 0.745 kb ;)Code:
2
3
4
Bonsoir,
J'aimerai signaler qu’il est inutile d’utiliser une API pour cela (dans le sens « pouvoir débogguer plus facilement ». Dans le sens importer plus facilement son fichier, pourquoi pas, même si cela se fait très simplement).
En effet, j’ai été confronté à ce problème récurrent (surtout lorsque j’utilise RequireJS pour une architecture modulaire), et en fouinant rapidement, j’ai vu qu’il est possible de mettre une ligne à la fin de son fichier, que les navigateurs reconnaissent : sourceURL
Cela permet de « nommer son fichier » (car le fichier n’est pas réellement chargé quand nous utilisons Ajax, il est exécuté dans un « eval »). Ainsi, lorsque ce dernier est chargé en Ajax, le navigateur lui associe un nom, et est facilement accessible dans le déboggeur Chrome et Firefox (et même dans des anciens).
Un exemple d’utilisation :
Code:
2
3
4
5
Du coup, j’ai pris comme bonne pratique de placer cette information en bas de tous mes fichiers JavaScripts. Permettant ainsi de se dédouaner d'un framework supplémentaire, et à moindre coût.
Pour de plus ample informations, voir le lien suivant : http://blog.getfirebug.com/2009/08/1...ith-sourceurl/
Cordialement
Bonjour indiana_jules,
C'est en effet une solution intéressante aussi. Par contre je n'ai pas réussi à le faire fonctionner avec $.getScript, je ne suis pas certain que la fonction $.getScript utilise la fonction eval().
Tu as déjà eu l'occasion de l'utiliser avec jQuery ?
C'est compatible avec les debogueurs natifs des navigateurs ?
En tout cas, merci pour l'info, c'est une bonne alternative ;)
Je viens d'essayer la solution d'indiana_jules dans mon code de test avec $.getScript, et ça fonctionne impeccablement. Le script est visible dans mes sources et je peux placer des breakpoints via l'inspecteur Web de Webkit.
Si quelqu'un a une référence des annotations en commentaires pour le navigateur telles que @ sourceURL, je suis preneur.
Bonjour,
D'après ce que j'ai pu voir / ressentir, je pense qu'un débuggeur de navigateur fonctionne de la manière suivante:
* Si le fichier est déclaré dans la page HTML, ou injecter via JavaScript (en ajoutant une balise <script>, <link> dans le header par exemple), le navigateur va prendre le nom (et le chemin) relatif au fichier (via l'attribut href ou src en fonction de la balise)
* Autrement, si nous souhaitons injecter du contenu via Ajax (qui utilisera eval), le navigateur cherchera dans le contenu @ sourceURL, afin d'associer le code exécuté plus facilement avec le navigateur. A noter que vous pouvez générer un javascript à la volée, l'exécuter avec eval, et si @ sourceURL est présent, il devrait apparaître dans le déboggeur du navigateur
Vu que le plugin $.loadScript injecte le JavaScript en utilisant la première méthode, @ sourceURL est donc ignorée.
D'après ce que j'ai pu voir aussi, c'est que les débuggeurs natifs, tel que celui de Chrome, ou additionnel comme Firebug, le reconnaissent. Cela me porte à croire que cela fait parti des usages et que le débuggeur est censé le prendre en compte.
Ce qui est intéressant avec @ sourceURL, c'est que du coup, nous nous soucions plus du tout de savoir par quel biais notre fichier JavaScript va être injecté.
Par exemple, j'utilise souvent RequireJS. Il va injecter mes scripts avec la première solution (me semble-t-il). Mais si la stratégie de chargement change, ou que j'utilise un framework qui privilégie le chargement en Ajax, ce sera transparent pour moi. Et je n'aurai pas besoin de faire des hacks / surcharges lourdes en JavaScript pour cela.
Cordialement
Il existe déjà un plugin JQuery de ce type, je l'utilise en production sur de gros site depuis plus d'un an.
http://www.arashkarimzadeh.com/jquer...avascript.html
Il permet de charger le JS ou le CSS et utilise un peu la même approche que celle que vous citez, à savoir créer un élément dans la partie HEAD pour charger le script supplémentaire.