Compréhension if - else

Version imprimable

Bonjour,

j'ai cherché très longtemps mais je n'arrive pas à comprendre mon erreur sur l'utilisation du if - else ? est-ce dû au type de variable (string, booléan....) ou à une erreur d'écriture mais j'avais cru comprendre que si la condition était remplie (true ou false) était rempli le code s'exécuter sinon un autre code

je dois faire une erreur sur la condition apparemment. C'est juste un entraînement et je suis autodidacte vous l'aurez compris.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 VOTRE NOM : <input type="text" id="nom" name="nom" onchange="REPONSE()" /> <script> function REPONSE() { var $nom=document.getElementById("nom").value; if ($nom != null) { alert("Bonjour " + $nom); } else { alert("Saisir votre nom !"); } } </script>
je cherche à comprendre la logique de la programmation. merci pour votre aide encore une fois

Bonjour
Le premier problème vient de null qui signifie que l'objet n'a ni type ni valeur
voir https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/null
Ici, la chaîne existe mais peut être vide

Code:

if ($nom >"")

conviendrait mieux
L'autre problème vient de

Code:

onchange="REPONSE()"

qui ne réagit pas si je n'ai rien modifié et simplement appuyé sur enter
j'ajouterais plutôt un bouton pour appeler ma fonction même si l'entrée est vide
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 <!DOCTYPE html> <html> <head> <meta charset=UTF-8> <title>tester if</title> <script> function REPONSE() { var $nom=document.getElementById("nom").value; if ($nom >"") { alert("Bonjour " + $nom); } else { alert("Saisir votre nom !"); } } </script> </head> <body> <form> VOTRE NOM : <input type="text" id="nom" name="nom" onchange="REPONSE()" /> <input type="button" value="Bouton validation" onclick="REPONSE();"> </form> </body> </html>

08/03/2018, 09h28
bricoreur

Bonjour

merci pour votre réponse qui me permet de mieux comprendre.

si je comprends bien pour réaliser des contrôles sur un formulaire entier je devrais faire appel via un bouton à l'ensemble des fonctions (avant de le soumettre) ?

Salut

Pour tes essais, utilise plutôt console.log car alert te bloque la suite du déroulement de ton programme.
Pour voir la console, F12 sous FireFox, onglet console.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function REPONSE()
{
 
        var $nom=document.getElementById("nom").value;
 
                if ($nom !== "")  
                  {
                console.log("Bonjour " + $nom);
                  }
                else
                  {
                console.log("Saisir votre nom !");
                  }
}

En sachant que le onchange est déclenché lors de l’appui de la touche ENTER ou lorsque l'input perd le focus.

08/03/2018, 10h07
Watilin
Salut,

attention avec les comparaisons en JS, comme dans certains autres langages à typage dynamique comme PHP (*).

Les opérateurs == et != font des comparaisons « laxistes », c’est-à-dire qu’ils vont faire des conversions implicites de type (coercitions — ou coercions en anglais) quand les deux valeurs comparées ne sont pas de même type. C’est un comportement qu’on cherche à éviter pour minimiser les mauvaises surprises.

Avec la comparaison laxiste, il y a un certain nombre de valeurs qu’on appelle « falsy » qui sont équivalentes à false :
- le nombre 0
- la chaîne vide ""
- undefined
- et bien sûr, false lui-même
Voir opérateurs de comparaison.

Attention en JavaScript null est de type object, c’est malheureux mais c’est comme ça. Voir The history of “typeof null”.

null ne fait pas partie des valeurs falsy. Ainsi, comparer "" à null aura un résultat négatif. Au moment de rédiger ce post, je me suis moi-même fait avoir, avant de vérifier je croyais que null était falsy. Retenir ce genre de détail est difficile et inutile ; de plus, l’algorithme de comparaison laxiste est effroyablement compliqué, et c’est se battre contre des moulins qu’espérer prédire son comportement dans toutes les situations.

Pour ces raisons, on préfère utiliser les opérateurs de comparaison dite stricte, qui s’écrivent === et !==, et qui ne font pas de coercition. En pratique, la comparaison a === b ne sera positive que si a et b sont de même type.

Pour conclure, @bricoreur je te suggère le test suivant :

Code:

if ($nom !== "")

(*) Pour compliquer encore les choses, les valeurs falsy de PHP ne sont pas les mêmes, mais je ne vais pas rentrer dans les détails.
08/03/2018, 11h33
Michel

Citation:

Envoyé par bricoreur

si je comprends bien pour réaliser des contrôles sur un formulaire entier je devrais faire appel via un bouton à l'ensemble des fonctions (avant de le soumettre) ?

On peut faire les deux, cela dépend du problème à résoudre.
Cependant si le champ est vide et qu'on appuie sur enter onChange ne fait rien et donc on a pas de message. C'est pourquoi, pour moi, les deux méthodes peuvent se compléter.
remarque :Le test proposé par ProgElecT

Code:

nom !== ""

est meilleur que celui que j'avais utilisé.
08/03/2018, 20h11
Loralina

Bonsoir,

Citation:

Envoyé par Watilin

null ne fait pas partie des valeurs falsy.

Bien vu. :)

Citation:

Ainsi, comparer "" à null aura un résultat négatif.

Oui, mais ce n'est pas tellement une conséquence logique (du fait qu'il ne fait pas partie du groupe) dans la mesure où inversement null==undefined vaut true (bon, on peut dire aussi que c'est l'exception qui confirme la règle, comme on dit).

Citation:

Attention en JavaScript null est de type object, c’est malheureux mais c’est comme ça. Voir The history of “typeof null”.

Mon impression :
typeof null donne en effet object pour la raison qu'on connaît.
En revanche, le type Null est tout de même bien référencé :
https://developer.mozilla.org/en-US/...ata_structures
La valeur null est bien considérée comme étant du type Null.
C'est juste typeof null qui renseigne mal.
D'ailleurs on peut voir ici qu'un correctif avait été proposé mais refusé :
https://developer.mozilla.org/fr/doc...9rateur_typeof

Citation:

l’algorithme de comparaison laxiste est effroyablement compliqué

J'ai essayé de l'appliquer au test null==false.
Sur cette page, c'est très vague au sujet de la conversion de type des opérandes :
Il ne s'agit pas forcément d'obtenir dans tous les cas deux opérandes du même type avant de passer à la comparaison stricte (quoique dans l'algorithme, il ne me semble pas être question d'une deuxième étape avec une comparaison stricte).
En effet, pour null==false, d'après l’algorithme :
Il me semble qu'on va à l'étape 7 de l'algorithme.
Ensuite, je me suis demandée s'il fallait recommencer l'algorithme et aller à l'étape 9 dans le cas où le type de null pourrait être considéré ici comme étant object.
Mais en fait non : quand on clique sur "Type", on voit que le type Null est bien possible.
Donc, après l'étape 7, on passe à l'étape 10 et on a false.
09/03/2018, 14h31
Watilin
Citation:

Envoyé par Loralina

Oui, mais ce n'est pas tellement une conséquence logique (du fait qu'il ne fait pas partie du groupe) dans la mesure où inversement null==undefined vaut true (bon, on peut dire aussi que c'est l'exception qui confirme la règle, comme on dit).

Exception, c’est le mot qui convient : les étapes 2 et 3 de l’algo sont là pour gérer spécialement ce cas.

Citation:

Envoyé par Loralina

J'ai essayé de l'appliquer au test null==false.
Sur cette page, c'est très vague au sujet de la conversion de type des opérandes :

J’imagine que les rédacteurs et redactrices de cette page n’ont pas voulu paraphraser tout l’algorithme :roll:

Citation:

En effet, pour null==false, d'après l’algorithme :
Il me semble qu'on va à l'étape 7 de l'algorithme.

Il me semble aussi.

Citation:

Ensuite, je me suis demandée s'il fallait recommencer l'algorithme et aller à l'étape 9 dans le cas où le type de null pourrait être considéré ici comme étant object.
Mais en fait non : quand on clique sur "Type", on voit que le type Null est bien possible.
Donc, après l'étape 7, on passe à l'étape 10 et on a false.

Du coup, le booléen false est converti en le nombre 0, et le résultat est celui de la comparaison null == 0, qui est false parce que… Eh bien, parce qu’il n’est pas true :aie:

Citation:

(quoique dans l'algorithme, il ne me semble pas être question d'une deuxième étape avec une comparaison stricte).

En fait, de ce que j’ai compris, on a une comparaison sans conversion si les opérandes sont déjà de même type au départ, c’est l’étape 1. Sinon, on a le cas particulier null == undefined et inversement, et ensuite, dans l’ordre :
1. les chaînes sont converties en nombres (avec potentiellement une conversion en NaN qui entraîne systématiquement un résultat false)
2. les booléens sont convertis en nombres : true en 1 et false en 0
3. les objets sont convertis en leur primitive : très souvent, ça va être un toString, sauf si on est masochiste et qu’on utilise les formes encapsulées (new Number, etc.). On notera en particulier que les tableaux sont convertis en chaîne, et qu’un tableau vide [] est converti en la chaîne vide "", par conséquent un tableau vide est falsy.
Autre chose, j’ai parlé un peu vite hier en disant qu’undefined était falsy , j’avais simplement évalué !!undefined, ça m’avait renvoyé false et pour moi c’était bon. Mais en réalité la comparaison undefined == false n’est pas vraie, parce que le type undefined n’est pas testé au-delà des étapes 1, 2 et 3 de l’algo, du coup avec autre chose que null, ça va directement à l’étape 10 et ça renvoie false.

Bon du coup voilà, à plusieurs on a réussi à décortiquer l’algo, mais je pense que demain j’aurai déjà tout oublié. Ça me paraît bien inutile d’apprendre ça par cœur, je préfère m’en tenir à la comparaison stricte :)

Edit : un peu de lecture…
- WTFJS, qui est à la fois drôle et déprimant
- Object to Primitive Conversions in JavaScript par Ben Cherry
10/03/2018, 10h14
Loralina

Bonjour,

Citation:

Envoyé par Watilin

j’avais simplement évalué !!undefined

J'avais fait la même chose avec null. :)
!!null = false, mais là ce sont les règles de conversion booléenne qui s'appliquent et non l'algorithme aux dix commandements ^^.
De même, if(null) = if(false).

Citation:

un tableau vide est falsy.

Pour [], c'est un peu l'inverse de ce qu'on constate avec null :
En effet, []==false = true, comme la chaîne vide et contrairement à null.
Cependant, contrairement à null et à la chaîne vide, !![] = true.
11/03/2018, 15h10
bricoreur

Merci pour toutes vos explications.

J’ai compris et résolu mon pb.

Cordialement
11/03/2018, 15h51
Watilin

Cool ! :ccool: N’oublie pas le bouton « résolu » ;)