Approfondissez vos connaissances en Javascript !

Bonjour, Je n'ai pas trouvé si je pouvais juste suivre ce topic sans faire de message, pour le retrouver facilement à ma prochaine visite. Il y a un bouton pour ça ? Thunderseb, est-ce que ce tuto est à peu près le même niveau que ce que tu avais fait sur OC, mais présenté différemment, ou c'est plus avancé ? Je n'ai pas le temps de le lire maintenant, mais si c'est un peu la "suite", ça m’intéresse. Je suis aussi intéressée par la programmation objet mais il semble que l'autre tuto en cours de rédaction ne fasse pas l'unanimité. Est-ce que tu comptes l'aborder, Vouivrer ?

C'est complémentaire. C'est une liste de rappels et de bonnes pratiques. Son but n'est pas d'enseigner le JavaScript, il faut déjà avoir une base correcte .

PS : bouton en haut à gauche "Suivre ce sujet"

Je suis aussi intéressée par la programmation objet mais il semble que l'autre tuto en cours de rédaction ne fasse pas l'unanimité. Est-ce que tu comptes l'aborder, Vouivrer ?

Oui oui je compte l'aborder dès que j'aurai un peu plus de temps libre devant moi !

D'ailleurs, j'ai déjà effleuré le sujet lorsque je parle des fonctions !

Je te laisse une liste non exhaustive de ce dont je vais parler à propos de ce sujet : - Présentation très brève du concept de l'orienté objet - Démonstration des attributs et des méthodes (j'en ai déjà parlé mais cette partie-là sera un rappel) - Ajout des variables et méthodes privées - Design pattern "Module Pattern" - Design pattern "SandBox" - Design pattern "Async / waterfall" - Design pattern "Promise"

Voilà un rapide aperçu de ce que je vais mettre. Je suis au courant qu'il manque des choses mais c'est juste une rapide énumération !

C'est complémentaire. C'est une liste de rappels et de bonnes pratiques. Son but n'est pas d'enseigner le JavaScript, il faut déjà avoir une base correcte

Je n'aurai pas dit mieux !

Salut, j'étais sûr d'avoir déjà commenté cet article, j'ai dû perdre mon message l'autre jour. :/

Bref, voici quelques commentaires :

Le hoisting est un mot décrivant le fait que toutes les déclarations sont automatiquement bougées vers le "haut" de notre fonction. Ce qui veut donc dire, que les variables déclarées au début, au milieu ou encore à la fin de notre fonction, seront déplacées vers le haut de celle-ci.

C'est pas correct, le truc hoisté (je suppose qu'on peut dire "hisser" en français) est hoisté au début du scope, pas au début d'une fonction en particulier.

Les différents types de boucles

Pourquoi ne pas parler while dans ce chapitre ?

Optimisation des boucles Ce qu'il faut savoir avec les boucles for, c'est que la condition est évaluée à chaque tour de boucle !

Je connais pas de moteur JS qui ne fait pas de Loop Invariant Code Motion optimization. T'as des exemples de ce que tu avances là ?

documentfragment La solution experte

Si je tombais sur cette boucle dans une codebase, je la refactoriserais immédiatement en Array.prototype.map.

Les closures Dans un jargon plus technique, une closure est un scope créé quand on déclare une fonction.

Non.

Une closure est une fonction qui référence/utilise des variables qui n'appartiennent pas au scope de la fonction en question.

Une closure est une fonction qui référence/utilise des variables qui n'appartiennent pas au scope de la fonction en question.

En plus de cette définition, je suis tombé là-dessus l'autre jour et j'en ai déduit que peut-être ma définition de closure n'était pas la bonne puisque ça me semble être un cas particulier, pas vraiment la définition.

Du coup je suis plus d'accord avec victor sur la définition : une closure est à mon sens un "truc" (en JS une fonction, en Groovy c'est un objet en fait) qui utilise des variables "non-locales". C'est plus général et ça permet de couvrir plus de langages.

Pour le hoisting y'a un bon exemple ici : slide 15

Réponse pour victor,

C'est pas correct, le truc hoisté (je suppose qu'on peut dire "hisser" en français) est hoisté au début du scope, pas au début d'une fonction en particulier.

Absolument ! Je corrigerai cette grossière erreur.

Pourquoi ne pas parler while dans ce chapitre ?

Hum… Excellente question. C'est certainement un oubli de ma part.

Je connais pas de moteur JS qui ne fait pas de Loop Invariant Code Motion optimization. T'as des exemples de ce que tu avances là ?

Pour être franc, je ne connais pas le moteur de JavaScript. D'ailleurs, je ne connaissais pas non le Loop Invariant Code Motion optimization. Mais tu es donc en train de me dire que la condition n'est pas évaluée à chaque tour de boucle ?!

Si je tombais sur cette boucle dans une codebase, je la refactoriserais immédiatement en Array.prototype.map.

Pourquoi pas ! Disons que c'est juste une autre alternative pour l'insertion de plusieurs éléments dans le DOM !

Une closure est une fonction qui référence/utilise des variables qui n'appartiennent pas au scope de la fonction en question.

Je remodèlerai ma phrase afin qu'elle colle à ton explication. En supplément, je vais faire encore plus de recherches à ce sujet.

Dans tous les cas, un grand merci pour ton intervention !

Réponse pour Javier,

En plus de cette définition, je suis tombé là-dessus l'autre jour et j'en ai déduit que peut-être ma définition de closure n'était pas la bonne puisque ça me semble être un cas particulier, pas vraiment la définition.

Oui c'est un cas qui utilise les caractéristiques d'une closure !

Pour le hoisting y'a un bon exemple ici : slide 15

Merci pour ces slides ! J'ai rapidement fait le tour et ça m'a l'air hyper intéressant !

Si si, la condition d'une boucle for est évaluée à chaque tour de boucle. D'où l'importance de placer le nombre de tours à effectuer dans une variable et éviter les table.length.

Pas V8, pas IonMonkey, pas Chakra… Je vois pas l'intérêt de parler des problèmes du moteur JS d'IE6 dans cet article.

Mon Firefox 38.5.2 a toujours ce comportement, je viens de tester à l'instant. Idem pour Chrome 47.

A mon avis on parle pas du même truc

Donne ton code et ta façon de tester stp.

Ca dépend (nécessairement ?) de la condition, non ? Dans certains cas je vois pas comment il pourrait l'extraire (motion).

Un exemple débile :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

var SomeObj = function() {};
someObj.prototype.length = function() {
  console.log('length !!');
  return 3;
};

var test = new SomeObj();
for(var i = 0; i < test.length(); i++) {
  console.log('within loop');
}

1
2
3
4
5
6
7

length !!
within loop
length !!
within loop
length !!
within loop
length !!

Il pourrait faire autrement que d'évaluer à chaque fois ?

Idem, j'avais fait :

1
2
3
4
5
6
7
8

function doo() {
    console.log("do");
    return 5;
}

for (var i=0; i<doo(); i++) {
    console.log("for " + i);
}

Sinon, recalcul du length :

1
2
3
4
5
6
7
8
9

var a = [0, 1, 2, 3];

for (var i=0; i<a.length; i++) {
    console.log("for " + i);

    if (i<10) {
        a.push(true);
    }
}

Non mais qu'on soit bien d'accord, je dis pas que toute loop est optimisée.

Il donne un exemple et dit que la condition sera évaluée à chaque tour. Or c'est pas le cas, du coup je conteste. (Et ThS surenchérit en parlant de table.length. Idem, c'est pas le cas.)

Je suis bien d'accord avec vos deux premiers exemples. Ils ne sont pas (encore) optimisés.

Le dernier exemple (ThS) est un peu hors de propos. Si tu mutes la variable sur laquelle est la condition, tu peux pas l'extraire de la boucle. Je dis qu'elle est hors de propos parce que la feinte de sioux présentée dans le tuto n'est pas utilisable sur cet exemple.

Mais vraiment, quand 99% des boucles for consistent en une comparaison avec xs.length, et quand 99% des utilisateurs ont un moteur qui optimise ça, présenter ça comme une optimisation est trompeur. (Et je parle pas du fait que 99% des boucles for sur des arrays devraient être remplacées par map/filter/reduce…)

Pour en avoir le coeur net, je vais faire un test de performance sur cette manière de faire. De plus, j'ai déjà vu plusieurs personnes qui, justement, l'avaient déjà réalisé et les résultats étaient concluants : la boucle a été optimisée suite à la technique que j'ai citée dans le tutoriel.

Si maintenant tu as des sources Victor, je ne suis absolument pas contre de les lire !

Une fois que j'aurai terminé mon test, je posterai, évidemment, ici le code en question.

Mon pote Mr. Aleph à la rescousse : http://mrale.ph/blog/2014/12/24/array-length-caching.html

J'avais un peu lu en vitesse tout à l'heure, je m'y suis remis avec quelques nouvelles remarques :

Partie 1 :

Quand on crée une variable sans le var , on crée une variable de type "global".

Maintenant, si justement on ne l'oublie pas, on crée une variable de type "local".

Tout ça risque de porter (pun) à confusion. Dans le premier cas, il s'agit d'une variable de portée globale. Dans le second, d'une variable de portée locale (function scope pour être précis). Dans les deux cas, les variables n'ont pas de type.

Idem ici :

Les variables de types "global"

l'hoisting.

Le hoisting

Je te suggère de choisir entre l' et le.

Comprende le hoisting

J'insiste énormément sur le mot déclaration ! Souvent déclaration et initialisation sont deux termes qui sont confondus. Prenez garde.

D'accord, mais pourquoi insister à cet endroit précis alors que tu parles d'hoisting ? var x; est tout aussi hoisté que var x = 1;, du coup je trouve l'avertissement un peu mal placé.

alert(pseudo);

Je te suggère de remplacer tous les alert par des console.log. Ca a le mérite de fonctionner partout. Ce serait dommage que tes lecteurs se mangent des ReferenceError en essayant de faire tourner le code que tu proposes.

Partie 2 :

De base, vos scripts sont chargés de manières synchrones. Ce qui veut dire que si jamais vous avez un fichier super volumineux à télécharger, votre code HTML ne sera pas affiché tant que le téléchargement ne sera pas terminé.

Alors, je connais mieux node que les browsers, MAIS je crois que ce que tu dis là est faux. J'ai pas vérifié, à prendre avec des pincettes. Il me semble qu'il s'agit d'une question d'exécution et non de téléchargement. Avant que par ex. webkit puisse afficher l'HTML, il faut qu'il télécharger le script, le parse et l'exécute.

(En fait je crois que j'ai pas besoin de vérifier. Si ce que tu disais était vrai, inliner le code dans des <script> placés en head résoudrait le problème du téléchargement.)

defer permet de charger vos fichiers de manière asynchrone

Du coup, pas seulement "charger".

Solution à privilégier car elle convint par sa facilité d'application

Moui. C'est correct, mais c'est pas vraiment la raison pour laquelle on privilige cette solution. On la choisit plutôt pour que ce ne soit pas bloquant.

Partie 3 :

Tu donnes l'exemple d'ajouter une méthode au prototype d'un objet de base du JS : Array. J'ai peur que ça donne de mauvaises idées aux gens qui apprennent grâce à ton tuto. C'est une pratique tellement mauvaise et dangereuse, source de tellement de problèmes, que soit j'éliminirais complètement cet exemple pour le remplacer par un autre (avec un objet de ton choix par exemple), solution que je préfère, soit tu expliques également pourquoi ajouter des méthodes aux prototypes de base est d'une bêtise incomparable.

Je passe sur forEach, même si je suis pas d'accord avec l'intérêt/l'utilité de forEach telle qu'écrite ici.

Si par exemple vous devez utiliser qu'une seule et unique fois une fonction, pourquoi ne pas faire une fonction anonyme ?

Pour ne pas avoir une stack-trace incompréhensible. Très souvent, les style-guides JS interdisent de ne pas nommer des fonctions.

Du coup, une fois que l'on exécute le code qui se trouve ci-dessous, on doit obtenir "[object Window]".

Uniquement dans une navigateur.

Félicitions, on vient juste de changer la valeur de notre this !

Non, c'est la valeur de this qui a changé. Tu ne peux pas changer la valeur de this. (rvalue je suppose)

Le curry

En français, on dit "la curryfication".

Démonstration

Pourquoi une grosse suite d'if/else et pas un switch ou un objet littéral ?

C'est tout pour ce soir. J'ai un peu l'impression de faire le boulot des validos JS ces jours.

Ok je vais prendre en compte toutes tes remarques afin d'améliorer un maximum ce tutoriel !

Un très grand merci pour toutes ces remarques très constructives !

Malheureusement, je dois bien avouer que j'ai très peu de temps. Je corrigerai donc toutes ces grossières erreurs dès que possible !