Quels sont les principaux pièges JavaScript?

Je préconise de faire une introduction sur le JavaScript et, dans le processus de préparation, je me demandais quels sont les pièges les plus élevés dans lesquels se situent les recrues.

Je sais que j'ai eu quelques contraintes avant que je comprenne complètement la fermeture, mais une grande partie du comportement étrange de JavaScript n'est plus un sujet dont je pense …

Alors, quels pièges devriez-vous signaler aux novices?

Conversion de type booléen .

'' == '0' //false 0 == '' //true 0 == '0' //true false == 'false' //false false == '0' //true false == undefined //false false == null //false null == undefined //true " \t\r\n" == 0 //true 

En plus de la différence entre null et undefined . Comme indiqué dans le tableau ci-dessus, la comparaison de null & undefined avec == renvoie true, mais avec === il renvoie false. Ce comportement est logique une fois que vous comprenez que undefined est très différent d'une variable ayant une valeur null , et quelque chose qui détient la valeur undefined est différent de ce qui est indéfini.

Ne laissez pas accidentellement une virgule arrière dans une définition d'objet littérale ou IE échouera et vous ne remarquerez pas beaucoup plus tard parce que vous n'utilisez jamais IE pour le développement et que d'ici là, vous pourriez imaginer ce qui s'est passé.

 var foo = { bar: "bar", baz: "baz", }; 

Note @ Commentaire de JulianR: Dans les tableaux, IE ne manque pas directement en lançant une erreur de syntaxe, mais échouera lorsque vous essayez d'utiliser le tableau car la virgule ajoutée fait IE penser qu'il y a un élément de plus dans le tableau, avec une valeur undefined , que Il y a effectivement. Donc, si vous avez déjà une erreur car, pour une raison quelconque, le dernier élément d'un tableau est undefined : c'est une virgule.

Certes, j'ai été coupable de certains dans le passé, pour votre amusement, ce sont les audacieux:

  • Ne sait pas les utilisations incorrectes (et les très peu correctes) de eval
     eval("obj."+prop); 
  • Utilisation with instructions
  • Utilisation de parseInt(str, base) sans préciser l'argument de base .
  • En utilisant this dans les fonctions timer / callback.
  • Utilisation d'expressions eval-like dans les horloges
     setTimeout("someFunc(myScopedVarWhoops)"); 
  • Penser que jQuery est le nom de la langue que vous codiez
  • Effectuer des tâches JavaScript simples en utilisant un cadre – $(1).plus(1) quiconque? 😉
  • L'utilisation continue sans incrémenter ou ajuster la variable conditionnelle.
  • Inondant l'espace de noms global avec des variables
  • Oublier var dans ou avant for déclarations. for (i=0;i<10;i++)
  • À l'aide d'un obscurcisseur et juste le laisser flasque sur votre code
  • Pas vraiment un piège, mais sans but – return condition ? true : false; return condition ? true : false; Au lieu de la return condition; de return condition;
  • Ne pas commenter votre code , s'applique vraiment à toutes les langues.
  • En utilisant try...catch...finally statements to catch errors au lieu d'utiliser les instructions if pour vérifier les variables.
  • Foolishly essayant d'arrêter "view source" en bloquant les clics de droite sur vos pages (j'étais jeune * sots * !)
  • En utilisant { 0: "Foo", 1:"Bar", 2:"Foobar" } au lieu de [ "Foo", "Bar", "Foobar" ]
  • Utilisation de parseInt() sur l'entrée de l'utilisateur
     parseInt("1,000") // -> 1, wrong! +"1,000" // -> NaN, correct! 

Certains ont déjà mentionné:

  • Ne pas utiliser l'égalité strictement ( === ) chaque fois que possible
  • Définir les gestionnaires d'événements à la valeur de retour d'une fonction au lieu d'une référence à ladite fonction
  • Non ; Terminer correctement les déclarations
  • Utilisation for...in boucles sur des tableaux

Peut penser un peu plus après avoir dormi 🙂

  • Oublier de déclarer des variables avec var
  • Mauvaise compréhension (ou pas compréhension) de la portée et des fermetures variables
  • Essayer de résoudre des problèmes de compatibilité méchants que les équipes de frameworks ont déjà résolues

+ Concaténer des chaînes:

 var a = '2'; var b = 3; a * b # 6 a - b # -1 a + b # 23 

Les chaînes JavaScript ne sont pas des chaînes d'octets, ni même des chaînes Unicode. Ils sont des chaînes UTF-16.

Exemple:

 > "♫".length 1 > "𐌈".length 2 > "𐌈".charAt(0) "\uD800" > "𐌈".charAt(1) "\uDF08" > "𐌈" === "\uD800\uDF08" true 

Si ce qui précède ressemble à des ordures, reprochez à votre navigateur de manipuler unicode buggy (ou éventuellement votre police, pour ne pas avoir le caractère 'OLD ITALIC LETTER THE').

Les plus grandes difficultés que je vois pour le débutant sont la compréhension du contexte d'exécution (c.-à-d. Ce que «cela» signifie à chaque fois et partout où il se trouve) et le prototype de système d'héritage.

  • Fermetures – autrement appelées fonctions lambda – attention aux fuites de mémoire.
  • Les différences entre les navigateurs, les tests dans Internet Explorer et au moins un autre navigateur sont indispensables. Les fonctions qui ne fonctionnent que dans certains navigateurs ou fonctionnent différemment dans différents navigateurs devraient généralement être évitées. Si cela n'est pas possible, la ramification spécifique au navigateur est mieux à même de détecter les fonctionnalités du navigateur au lieu des versions du navigateur. Cela augmente les chances que le code fonctionne dans les futurs navigateurs et navigateurs qui n'ont pas été testés.
  • Être trop pris dans l'abstraction du cadre jQuery ou Ajax , et ne pas savoir le JavaScript souligné assez bien pour savoir comment résoudre les problèmes de cadre.
  • Sans savoir que JavaScript peut être utilisé dans une certaine mesure pour écrire le code OOP. En fait, il peut vous donner un cadre OOP très basique avec des objets.
  • Sensibilité aux cas (si vous êtes un développeur VB.NET )
  • Protection IP – sachant que vous pouvez obscurcir JavaScript, mais le code source que vous avez mis là-bas sera très facile à voler et à faire de l'ingénierie inverse. Cela pourrait même ne pas constituer un problème en fonction de la complexité de l'application côté client que vous écrivez.

Je ne peux plus penser, mais j'espère que cela vous aidera.

  • Utilisation de window.onload = init(); Au lieu de window.onload = init;
  • Equivalences booléennes (comme mentionné précédemment)
  • Fermeture dans une boucle.
  • Utilisation for in variante for in boucle pour l'itération sur les Arrays.
  • Ne pas utiliser ; Parce que c'est "facultatif".
  • this (juste … en général :))
  • Ne pas utiliser var
  • Sachant que obj.ref === obj["ref"]
  • Création de sites qui ne fonctionnent pas sans JavaScript
  • Utilisation de JavaScript pour les choses qui devraient être faites côté serveur
  • Utilisation de frameworks pour des tâches simples qui ne les nécessitent pas

Tout le concept de prototypage prend un certain temps pour comprendre complètement, mais voici quelques pièges communs:

Oublier de réinitialiser la propriété constructeur après avoir assigné un prototype d'objet:

 var Foo() = function () { this.batz = '...'; }; Foo.prototype = new Bar(); Foo.prototype.constructor = Foo; 

Si vous oubliez la moindre ligne, le new Foo() exécutera actuellement Bar() .

Un autre piège avec le prototypage est itérer sur des objets / tableaux sans filtrer les membres du prototype:

 for (var i in obj) { if (obj.hasOwnProperty(i)) { //stuff... } } 

La condition supplémentaire sautera les membres qui sont hérités du prototype d' obj .

Pas un piège de codage réel, mais plus une réflexion générale:
Ne faites pas confiance à ce que votre JavaScript fait, il aurait pu être éteint ou même corrigé par un singe . Cela signifie que vous ne comptez jamais sur la validation côté client. JAMAIS.

 typeof null is object >>> var i = 1 + undefined; i; NaN >>> var i = 1 + null; i; 1