Discussion :

[fredoche]

Salut

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

j'ai cette expression :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

qui apparait dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Watilin]

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.

[NoSmoking]

Bonjour,

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

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

[sekaijin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

A+JYT

[NoSmoking]

bien vu j'en avais oublié cette optimisation diabolique

[Watilin]

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

[fredoche]

la vache ...

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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"
}

[fredoche]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Watilin]

À 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

if (x == a) b;

[sekaijin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code qui marche

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[SylvainPV]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[NoSmoking]

J'ai également commis du code du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ||.

[fredoche]

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 :

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 , 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

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 ||
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 !

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

[Watilin]

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 =

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[fredoche]

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.

[Kaamo]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var a  =  true, 
    b  =  function() {
      // code ...
    };
if (a) {
  b();
}

Code minifié :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[SylvainPV]

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

[NoSmoking]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
function action( opt){
  opt = opt || {};
  opt.action = opt.action || function(){};
  // du code
  opt.action; 
}

...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.

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.

[fredoche]

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

ah mais tout à fait

j'aime beaucoup le topic que tu as initié je crois, sur le code JS en un tweet 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