comprendre une expression JS

Salut

Dans un plug-in jquery : https://github.com/mathiasbynens/jqu...placeholder.js

j'ai cette expression :

Code:

---

input == document.activeElement && input.select();

---

qui apparait dans

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

function clearPlaceholder(event, value) { var input = this, $input = $(input); if (input.value === $input.attr('placeholder') && $input.hasClass('placeholder')) { if ($input.data('placeholder-password')) { $input = $input.hide().next().show().attr('id', $input.removeAttr('id').data('placeholder-id')); // If `clearPlaceholder` was called from `$.valHooks.input.set` if (event === true) { $input[0].value = value; return value; } $input.focus(); } else { input.value = ''; $input.removeClass('placeholder'); input == document.activeElement && input.select(); } } }

---

Quelqu'un saurait il me traduire ce que l'auteur veut faire avec cette expression et comment cette expression est censée fonctionner dans le cadre de la fonction ?

En JS, les opérateurs && et || font des courts-circuits : si l'opérande gauche permet de connaître le résultat, l'opérande droite n'est pas évaluée.

Autrement dit dans une expression A && B, si A est false, on renvoie false et on passe à la suite, sans toucher à B.

Dans notre cas, l'opérande gauche est document.activeElement, c'est-à-dire l'élément qui a actuellement le focus. L'auteur a voulu (pour une raison qui m'échappe) que l'input ne soit pas sélectionné si aucun élément n'a le focus au moment où la fonction s'exécute.

Bonjour,

Citation:

---

input == document.activeElement && input.select();

---

le double == est un test et ne modifiera pas la valeur de input, donc un test qui sert à :koi:

c'est un test qui vérifie que l'élément actif est bien celui qui est référencé par la variable input avant d'effectuer l'action input.select()

cela revient à

Code:

---

1 2 3

if(input == document.activeElement) { input.select(); }

---

A+JYT

bien vu j'en avais oublié cette optimisation diabolique :aie:

Bien vu Sekaijin, je suis tombé dans le panneau moi aussi "^^

la vache ... 8O

Merci messieurs et merci sekaijin
Je présume que cela peut toujours se traduire comme cela.

je vais essayer de trouver des références là-dessus

Comme l'a dit Waitilin, && et || sont des "court-circuits".

Avec &&, tant que c'est true, on continue. Dès qu'un false survient, le reste n'est jamais évalué.

Avec ||, tant que c'est false, on continue. Dès qu'un true survient, le reste n'est jamais évalué.

C'est pour ça que la forme avec && est utilisée pour remplacer le if dans certains cas.
Et que la forme avec les || est utilisée pour simuler les valeurs par défaut lorsque de la déclaration de variables.

Code:

---

1 2 3

if (a && b) { // je fais ça }

---

&& implique que toutes les conditions soient vraies pour que l'ensemble soit vrai.

Donc, si a est à false, rien ne sert de vérifier les suivantes car l'ensemble sera toujours false. Par contre, si a est à true, le reste est évalué. Si c'est une fonction elle le sera, d'où cette forme réduite.

A l'inverse,

Code:

---

1 2 3

if (a || b) { // je fais ça }

---

|| implique qu'au moins une des conditions soit vraie pour que l'ensemble soit vrai.

Donc, si a est à true, rien ne sert de vérifier les suivantes. Par contre, s'il est faux, on continue d'évaluer ! C'est comme ça que l'on peut simuler par exemple les paramètres par défaut aux fonctions :

Code:

---

1 2 3

function toto(a) { var a = a || 'par défaut'; // Si a n'est pas renseigné, ou est "falsy", elle prendra la valeur "par défaut" }

---

la logique booléenne ne m'échappe pas, cela dit je ne connaissais pas cette notion d'évaluation en court-circuit de gauche à droite.

Je pense d'ailleurs que de connaitre ce mécanisme remet un peu en cause mes connaissances sur les propriétés des opérateurs booléens. A la limite plus besoin de chercher à simplifier, pour les quelques fois où ça m'arrive quand je gère plusieurs conditions.

Et puis ce qui me gratte beaucoup, c'est que ce soit un test de la forme x == a && b

qui se transforme en

Code:

---

1 2 3 4

if (x==a){ b; }

---

Maintenant court-circuit, plus la traduction de seikajin sous le nez, je comprends.

Mais je ne suis pas fan du tout de cette syntaxe

À vrai dire j'ai utilisé cette forme pendant quelques temps, car j'aime bien quand les choses tiennent en une ligne. Mais quand j'ai décidé que la lisibilité de mon code était plus importante, j'ai opté pour cette solution :

Code:

---

if (x == a) b;

---

Citation:

---

Envoyé par Kaamo

Comme l'a dit Waitilin, && et || sont des "court-circuits".

Avec &&, tant que c'est true, on continue. Dès qu'un false survient, le reste n'est jamais évalué.

Avec ||, tant que c'est false, on continue. Dès qu'un true survient, le reste n'est jamais évalué.

C'est pour ça que la forme avec && est utilisée pour remplacer le if dans certains cas.
Et que la forme avec les || est utilisée pour simuler les valeurs par défaut lorsque de la déclaration de variables.

Code:

---

1 2 3

if (a && b) { // je fais ça }

---

&& implique que toutes les conditions soient vraies pour que l'ensemble soit vrai.

Donc, si a est à false, rien ne sert de vérifier les suivantes car l'ensemble sera toujours false.
...

---

en fait les oppérateurs && sont très utile car ça va plus loin que ça.

Code:

---

1 2 3

if ((null != a) && a.isValid()) { // je fais ça }

---

la raison d'exister de l'opperateur est que la suite de l'expression ne sera évalué que si la première est vrai dan son exemple le ne peux pas test a.isValid() si a n'existe pas. un simple AND ne fonctionnerait donc pas
code qui ne marche pas

Code:

---

1 2 3

if ((null != a) AND a.isValid()) { // je fais ça }

---

Code qui marche

Code:

---

1 2 3 4 5

if (null != a) { if (a.isValid()) { // je fais ça } }

---

il n'est donc pas question de nécessité mais de possibilité.
il en va de même avec l'opperateur ||

Code:

---

1 2 3

if ( (! a.hasNext()) || a.getNext().isInvlid()) { je fais cela }

---

dans ce cas si je mets un simple ou j'ai un null exception en effet si a n'a pas d'élément suivant l'appel a getNext va retourner null et isInvalid plantera il ne faut donc pas appeler getNext si la première expression est vrai

c'est une forme d'optimisation mais c'est surtout une évaluation conditionnelle.
A+JYT

Il m'arrive de faire ce genre de raccourcis pour les appels de fonction avec un test trivial genre

Code:

---

a instanceof IceCream && MIAM();

---

Mais bon c'est comme les conditions ternaires, il ne faut pas en abuser si les collègues commencent à faire de gros yeux.

J'ai également commis du code du style

Code:

---

prop.callBack && prop.callBack(); // exécution de la propriété si existe

---

mais je suis revenu depuis à une écriture plus classique car moins ambiguë à long terme, et en ajoutant une initialisation via l'opérateur ||.

Citation:

---

Envoyé par NoSmoking

mais je suis revenu depuis à une écriture plus classique car moins ambiguë à long terme, et en ajoutant une initialisation via l'opérateur ||.

---

Voui ...

mais encore ?

Bon à vrai dire je suis arrivé sur cette question car je bascule petit à petit sous JSLint, mode strict, tout ça...

J'ai besoin d'un placeholder, la propriété n'existe pas sous IE8, je dois supporter IE8, donc je cherche une alternative, que voici sous la forme d'un plug-in JQuery. Avant d'intégrer des trucs maintenant je les JSLint.

Sikajin ton usage est très intéressant. Dis moi si je me trompe mais tu restes à travailler avec des valeurs booléennes ? En tout cas dans ce que je lis, je n'ai pas l'impression que tes fonctions renvoient autre chose que du booléen ?
Et vu comme ça je trouve ça puissant. C'est lisible, on reste dans du booléen, on profite du court-circuit, cool

Par contre les autres formes que vous avez l'air de plus ou moins abandonner jouent sur cette faculté de ces opérateurs logiques :

Citation:

---

However, the && and || operators actually return the value of one of the specified operands, so if these operators are used with non-Boolean values, they may return a non-Boolean value.

---

https://developer.mozilla.org/en-US/...ical_Operators
Et ça c'est chaud je trouve... super ça rend service aux petits malins :ccool:, mais ...

Je pense que tout le monde s'attend à ce que les opérateurs logiques renvoient une valeur booléenne. Non ?
Bon là encore je comprends mon manque de maitrise du langage, mais ce genre de truc, youhou, je dois pas être le seul.

Bon bref JSlint plante sur cette ligne. Je suis assez convaincu de l'intérêt de JSLint, notamment pour en finir avec les optimisations de petits malins où tu gagnes 3 caractères et tous ceux qui te relisent des maux de têtes, celle là c'en est une à mes yeux.

D'ailleurs je relis le 1er message de Watilin, et il parle de

Citation:

---

Dans notre cas, l'opérande gauche est document.activeElement

---

Et donc il a bien vu l'évaluation en court-circuit mais est passé à coté de la priorité des opérateurs :
http://msdn.microsoft.com/fr-fr/libr...=vs.94%29.aspx
https://developer.mozilla.org/en-US/...tor_Precedence
où l'on voit d'ailleurs que && est prioritaire sur || :mouarf:
donc la première opérande est le résultat du test ==

Rien qu'une petite parenthèse aurait facilité la lecture... 2 caractères en plus, non mais on va où ohhh !:aie:

Bref voilà qui justifie du JSLint et des pratiques un peu plus "human readable"

En fait quand on a l'habitude c'est plutôt intuitif que == soit prioritaire sur && (mais quand j'ai un doute, la page « Operator Precedence » du MDN est ma référence). Du reste, tu as bien vu à quel endroit je m'étais gourré, sauf que c'est une autre erreur que j'ai faite : j'avais lu trop vite, je croyais que c'était une affectation = :oops:

Globalement j'ai abandonné && au profit d'un if plus lisible, mais quant au || je ne vois pas de façon plus simple de faire une « affectation avec valeur par défaut ». Kaamo en a déjà parlé. C'est quand même une pratique courante donc je pense qu'il faut la connaître.

Un petit exemple ? De nombreux plugins jQuery (et même des méthodes « core » comme $.ajax) acceptent un objet pour les options, comme ça l'utilisateur peut en passer autant qu'il veut, dans l'ordre qu'il veut.

Code:

---

1 2 3 4 5

$.fn.pluginMachin = function( options ){ options = options || {}; var optionA = options.optionA || "defaultA"; ... };

---

Pour finir, ça va de soi que je continue à utiliser && et || pour leur usage booléen classique ;)

Sous forme d'affectation, pas de souci

C'est vrai que cette gestion des valeurs par défaut, je la vois partout, elle ne m'a surement jamais choqué.

comme tu le dis toi-même, tu as vu une affectation à la 1ere lecture. Ca montre quelque part la difficulté de cette syntaxe.

ce que je vois c'est que c'est seikajin qui a su lire l'expression en 1er, pourtant vous avez pas l'air de branquignolles en javascript.

le ternaire pas de souci, ces formes là me paraissent plus piégeuses, surtout celle de ma question.
Maintenant que j'ai buté dessus, travaillé dessus, cherché à propos, le truc est intégré pour ma part.

A mettre dans le prochain quizz javascript, voir qui maitrise cette syntaxe en réalité...

Enfin bon rien de grave de toute façon. Mais je me dis, et c'est mon strict avis personnel à moi, d'amateur débutant profane newbie de ce langage que je trouve intéressant à de nombreux titres, il est des optimisations qui n'en sont absolument pas. D'autant plus avec des les minifiers actuels. Je me laisserai aller à être vulgaire que je rapprocherai ça de l'onanisme intellectuel.

pareil pour les commandes d'une ligne qui font l'entrée, le plat et le dessert.
C'est rigolo comme gym cognitive, mais j'ai peur que ça s'arrête là en terme d'intérêt à l'heure actuelle.

Citation:

---

D'autant plus avec des les minifiers actuels. Je me laisserai aller à être vulgaire que je rapprocherai ça de l'onanisme intellectuel.

---

Tu as tout à fait raison. Autant être le plus lisible possible, les minifieurs actuels étant pour la plupart performants pour faire ce genre de chose.

Exemple Google Closure Compiler :

Code de dév :

Code:

---

1 2 3 4 5 6 7

var a = true, b = function() { // code ... }; if (a) { b(); }

---

Code minifié :

Code:

---

var a=!0,b=function(){};a&&b();

---

L'onanisme intellectuel c'est sympa aussi. Kaamo ne me contredira pas :mouarf:

Citation:

---

Voui ...

mais encore ?

---

rien de plus que ce qui vient d'être écrit par la suite à savoir que prop.action && prop.action() n'est pas forcément lisible quand on revient plus tard dans le code, ça fait "pro" mais à l'usage...boff!!!
J'en suis donc revenu et écris dorénavant

Code:

---

1 2 3

if( prop.action){ prop.action(); }

---

10 ans après la lecture reste claire, simplement à la différence de Watilin je mets une double accolade :lol:

Mais dans pas mal de cas, via l'initialisation avec le ||, on peut se passer du test

Code:

---

1 2 3 4 5 6

function action( opt){ opt = opt || {}; opt.action = opt.action || function(){}; // du code opt.action; }

---

Citation:

---

...comme tu le dis toi-même, tu as vu une affectation à la 1ere lecture. Ca montre quelque part la difficulté de cette syntaxe.

---

il arrive que lorsque l'on arrive sur le forum on l'aborde sous un mauvais contexte, pour ma part j'ai fait la fixette sur le test d'égalité...et pour sekaijin c'est l'oeil de lynx qui a parler. Il n'en reste pas moins que l'on en revient à la lisibilité pour tous.

Citation:

---

il est des optimisations qui n'en sont absolument pas.

---

Après de rapides tests, sur plusieurs navigateurs, il s'avère même que dans le cas où la condition est VRAIE alors les deux écritures se valent avec un tout petit avantage pour la méthode classique. Dans le cas où la condition est FAUSSE la méthode classique prend le dessus mais de peu et encore, vu le nombre de boucles le résultat reste pour moi le même.

Citation:

---

Envoyé par SylvainPV

L'onanisme intellectuel c'est sympa aussi. Kaamo ne me contredira pas :mouarf:

---

ah mais tout à fait :)

j'aime beaucoup le topic que tu as initié je crois, sur le code JS en un tweet :ccool: les exemples commentés de chacun, j'apprends plein de choses.

mais ce n'est pas une fin en soi, pour notre travail au quotidien.

d'ailleurs l'optimisation se situe ailleurs, plus globale, entre chargement de la page et des composants, html, et SGBD

Citation:

---

Envoyé par NoSmoking

...
J'en suis donc revenu et écris dorénavant

Code:

---

1 2 3

if( prop.action){ prop.action(); }

---

10 ans après la lecture reste claire, simplement à la différence de Watilin je mets une double accolade :lol:

---

Je mets mois aussi les accolades.

il y a des années voici ce qui met arrivé :
dans un dev (56 000 lignes de code environ) un developpeur à écrit une méthode très bien documenté. et dans un passage il fait un test et en dessous mets un gros commentaire du pourquoi du comment il fait appel à une fonction.
les années passent et un autre développeur intervient en urgence pour dépanner la chose suite à un changement de contexte. il commente l'appel à la fonction est ajoute un commentaire en MAJUSCULE pour alerter sur le fait que la rustine doit être corrigé. les tests se passent bien et le truc par en production
quelque temps plus tard je suis appelé à la rescousse car un bug apparemment aléatoire se produit.

voici ce qu'il se passait

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

if (macondition) /* ici le gros commentaire d'origine   ...                             sur beaucoup de lignes   */ #appelDeLaFunction(); //Désactivé en urgence /* ici GROS COMMENTAIRE SUR LA DESACTIVATION DE LA LIGNE DU DESSUS   ...                   lui aussi sur plusieurs lignes   */   /* commentaire sur le parcours de la boucle */ while(myvar in collection) { }

---

ceux qui on un oeil averti auront peut être vu qu'en commentant appelDeLaFunction(); la boucle while était soumise à la condition if (macondition).
c'était à l'époque du franc mais l'unité de base dans ce truc était le GF giga franc je vous laisse imaginer la panique lorsque le truc à produit des erreurs de l'ordre de la dizaine de GF.

A+JYT

J'y tiens à mon if en une ligne, et je pense qu'il est fool-proof :) Je vais tenter de vous expliquer pourquoi.

Code:

---

if (condition) instruction;

---

À la lecture, aucun doute possible, même si on est fatigué ou si on (re)découvre le code. L'instruction appartient au if, et les instructions suivantes non.

À l'écriture, si je veux rajouter une instruction dans le if, je suis obligé de passer à la ligne, vous me suivez ? Et au moment de passer à la ligne, je rajoute les accolades.

Code:

---

1 2 3 4

if (condition) { instruction; instruction; }

---

Et je ne crois pas qu'il soit possible d'oublier les accolades à ce moment-là. Vous n'êtes pas d'accord ?

Comme tu l'écris, pourvu que tu te tiennes à toujours l'écrire sur la même ligne, ça va.

Je rencontre parfois la forme où l'instruction est à la ligne suivante, juste décalé d'un tab (avec un peu de chance), et si c'est moi qui le lit, je rajouterai les accolades. Sinon mon cerveau a du mal.

JSLint t'obligerait à mettre les accolades, je viens de vérifier.

Code:

---

1 2	if (condition) instruction; instructionDeux;

---

ça me choque maintenant, même en sautant une ligne après la condition.

Avant je m'octroyais ce droit mais quand je repasse sur mon code j'ajoute systématiquement des accolades.

il y a aussi les if ... else if ... else qui utilise cette faculté d'accolades optionnelles si l'instruction est unique

Code:

---

1 2 3 4 5 6 7 8

if (truc) { //... } else if (bidule) {   } else {   }

---

elseif existe dans d'autres langages, tandis que là nous avons bien 2 ifs indépendants.
Ca revient certainement au même qu'un elseif mais il faut garder dans un petit coin de l'esprit comment/pourquoi ça fonctionne.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

if (truc) { //... } else { if (bidule) { //... } else { //... } }

---

tu utiliserais quelle version kaamo ?

En effet, c'est bien d'en avoir conscience ;)

Mais j'adopte le style de beaucoup de "grands comptes" (jQuery, Crockford, etc). Ce qui est quand même plus intuitif et lisible.

Code:

---

1 2 3 4 5 6 7

if (condition) { statements } else if (condition) { statements } else { statements }

---

Qui est, comme tu l'as dit, le raccourci de ceci.

Code:

---

1 2 3 4 5 6 7 8 9

if (condition) { statements } else { if (condition) { statements } else { statements } }

---

Mais quand le else if intervient je me pose toujours la question de le remplacer par quelque chose d'autre ! Soit un switch qui est souvent plus adapté. Ou alors il y a peut-être une mauvaise conception dans l'air.

Exemple bateau, que je vois parfois dans certains codes :

Code:

---

1 2 3 4 5 6 7

if (animal.estUneGrenouille()) { animal.coasse(); } else if (animal.estUnChien()) { animal.aboie(); } else if (animal.estUnLion()) { animal.rugit(); }

---

Ici, on pourrait penser à un switch, mais le polymorphisme serait plus adapté. Tout se passe en amont au moment de la création des objets, il faut les assigner au bon prototype

Code:

---

animal.crier()

---

Le grand débat du passage à la ligne avec if :) Je n'ai jamais su me décider, du coup je n'utilise plus que des conditions ternaires.

Code:

---

condition ? (function(){ instruction; })() : null;

---

:aie:

Non sérieusement ça n'a pas autant d'importance que certains voudraient y prêter. Je connais quelques collègues qui seraient prêts à s'engueuler pour ça :roll:

rooohhh :mrgreen:

là je sens qu'il y a un truc

Citation:

---

Envoyé par Kaamo

Mais quand le else if intervient je me pose toujours la question de le remplacer par quelque chose d'autre ! Soit un switch qui est souvent plus adapté. Ou alors il y a peut-être une mauvaise conception dans l'air.

Exemple bateau, que je vois parfois dans certains codes :

Code:

---

1 2 3 4 5 6 7

if (animal.estUneGrenouille()) { animal.coasse(); } else if (animal.estUnChien()) { animal.aboie(); } else if (animal.estUnLion()) { animal.rugit(); }

---

Ici, on pourrait penser à un switch, mais le polymorphisme serait plus adapté. Tout se passe en amont au moment de la création des objets, il faut les assigner au bon prototype

Code:

---

animal.crier()

---

---

Bon je vais aller me documenter sur ce concept qui m'échappe, mais si tu as envie de développer un petit peu, fais moi plaisir... :aie:

C'est bien toi qui nous sert du duckducktyping :mouarf: ça te travaille quand même

Citation:

---

Envoyé par Kaamo

En effet, c'est bien d'en avoir conscience ;)

Mais j'adopte le style de beaucoup de "grands comptes" (jQuery, Crockford, etc). Ce qui est quand même plus intuitif et lisible.

---

Aparté, je l'ai adopté comme professeur Crockford

la série de vidéos ici est vraiment passionnante :
http://yuiblog.com/crockford/
C'est un personnage très intéressant
Et clairement il change ma vision de ce langage, ainsi que vous ici.

Je vais aller regarder ces liens

J'avais vu passer un truc il y a quelques temps comme quoi le if c'était le mal et qu'il fallait passer par autre chose, notamment du polymorphisme.
Mais c'est dans des cas bien précis quand même. Bien sûr que le if est indispensable, mais pas tout le temps.

Si on reprend l'exemple ci-dessus, l'animal doit crier différemment selon son type. On peut imaginer un système simple, comme ci-dessus, avec des if imbriqués.

Mais aussi, on peut imaginer cela autrement. Bon il faut avouer que l'exemple est bidon, mais c'est pour illustrer.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

var Animal = { crie: function() { return "je n'ai pas de cri spécifique"; } };   var Grenouille = Object.create(Animal); Grenouille.crie = function() { return "crôa crôa !"; }   var Lion = Object.create(Animal); Lion.crie = function() { return "grôôôâr grôôôâr !"; }   var Chien = Object.create(Animal); Chien.crie = function() { return "woof woof !"; }   var ET = Object.create(Animal);   var animal = Object.create(Chien); // ou Lion, ou Grenouille animal.crie(); // woof woof !   var animal = Object.create(ET); animal.crie(); // je n'ai pas de cri spécifique

---

Et de la même façon, les for/while pourraient être remplacés par des fonctions/objets itérateurs. C'est vrai, toutes les petites instructions logiques qu'on a l'habitude d'utiliser pourraient être remplacées par un équivalent "orienté objet". On a jamais su sortir complètement de la programmation séquentielle, ça paraîtrait inimaginable de manipuler un langage sans if et sans for. Et comme tous les trucs inimaginables, ça m'intéresse beaucoup :)
Quelqu'un veulent tenter une petite expérience à base d'Object.prototype pour trouver un équivalent à tous les patterns séquentiels usuels ?

Héhé l'idée est à creuser ! ça sent le JavaScript ludique, saison 3, ça ! :D
Il semblerait qu'il y ait déjà eu des mouvements anti-if et anti-for par le passé