What is the difference between the !== operator and the != operator in JavaScript? Does it behave similarly to the === operator where it compares both value and type?
Yes, it's the same operator like ===, just for inequality:
!== - returns true if the two operands are not identical. This operator will not convert the operands types, and only returns false if they are the same type and value. —Wikibooks
Yes, !== is the strict version of the != operator, and no type coercion is done if the operands are of different type:
0 != '' // false, type coercion made
0 != '0' // false
false != '0' // false
0 !== '' // true, no type coercion
0 !== '0' // true
false !== '0' // true
I was about to post this W3Schools page, but funnily enough it didn't contain this operator!
At least, the !== is indeed the inverse of === which tests the equality of both type and value.
Related
This question already has answers here:
why null==undefined is true in javascript
(6 answers)
Closed 1 year ago.
How is null equal to undefined and not equal to undefined within the same operator.
undefined == null
true
undefined !== null
true
undefined === null
false
undefined != null
false
== converts the variable values to the same type before performing the actual comparison(making type coercion)
=== doesn't do type coercion and returns true only if both values and types are identical for the two variables being compared.
Let's take a look at some examples:
console.log(5 == "5"); // no type coercion is being made - hence, the result is true.
console.log(5 === "5"); // type coercion is being made, value is the same but the data types are not (number vs string);
console.log(undefined == null); // should be true because type coercion is not being made and the data values are both falsy!
console.log(undefined !== null); // should be true cause type coercion is being made and the data types are differnt!
console.log(undefined === null); // // should be false cause type coercion is being made and the data types are differnt.
console.log(undefined != null); // should be false cause type coercion is not being made and the data values are both falsy!
Undefined and null are empty variables. But to understand whats above you have to understand comparison operators. == is a comparison operator that can convert. === really tests if its the same without doing type conversion. So null is practically the same as undefined. Its a bit hard to understand when you first think about it but its really not that hard. Some examples:
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
Please find my answer below.
"==" coerces the type of the variable before making a comparison.
i. so undefined == null is true since both the variables coerces to false (since they both indicate an empty value) and post that comparison is made making them equal.
!== makes a strict comparison so the type is not changed, in case of undefined the type is "undefined" and in case of null the type is "object" which can be verified using typeof.
ii. so since the type does not match,!== return true i.e. undefined !== null.
iii. Same way === makes a strict comparison, so undefined === null is false, since the type is only different
iv. Lastly undefined != null is false, since != like == coerces the type of the variables to false, and then compares. Hence they both seem equal to != and it return false.
I had to write a routine that increments the value of a variable by 1 if its type is number and assigns 0 to the variable if not, where the variable is initially null or undefined.
The first implementation was v >= 0 ? v += 1 : v = 0 because I thought anything not a number would make an arithmetic expression false, but it was wrong since null >= 0 is evaluated to true. Then I learned null behaves like 0 and the following expressions are all evaluated to true.
null >= 0 && null <= 0
!(null < 0 || null > 0)
null + 1 === 1
1 / null === Infinity
Math.pow(42, null) === 1
Of course, null is not 0. null == 0 is evaluated to false. This makes the seemingly tautological expression (v >= 0 && v <= 0) === (v == 0) false.
Why is null like 0, although it is not actually 0?
Your real question seem to be:
Why:
null >= 0; // true
But:
null == 0; // false
What really happens is that the Greater-than-or-equal Operator (>=), performs type coercion (ToPrimitive), with a hint type of Number, actually all the relational operators have this behavior.
null is treated in a special way by the Equals Operator (==). In a brief, it only coerces to undefined:
null == null; // true
null == undefined; // true
Value such as false, '', '0', and [] are subject to numeric type coercion, all of them coerce to zero.
You can see the inner details of this process in the The Abstract Equality Comparison Algorithm and The Abstract Relational Comparison Algorithm.
In Summary:
Relational Comparison: if both values are not type String, ToNumber is called on both. This is the same as adding a + in front, which for null coerces to 0.
Equality Comparison: only calls ToNumber on Strings, Numbers, and Booleans.
I'd like to extend the question to further improve visibility of the problem:
null >= 0; //true
null <= 0; //true
null == 0; //false
null > 0; //false
null < 0; //false
It just makes no sense. Like human languages, these things need be learned by heart.
JavaScript has both strict and type–converting comparisons
null >= 0; is true
but
(null==0)||(null>0) is false
null <= 0; is true but (null==0)||(null<0) is false
"" >= 0 is also true
For relational abstract comparisons (<= , >=), the operands are first converted to primitives, then to the same type, before comparison.
typeof null returns "object"
When type is object javascript tries to stringify the object (i.e null)
the following steps are taken (ECMAScript 2015):
If PreferredType was not passed, let hint be "default".
Else if PreferredType is hint String, let hint be "string".
Else PreferredType is hint Number, let hint be "number".
Let exoticToPrim be GetMethod(input, ##toPrimitive).
ReturnIfAbrupt(exoticToPrim).
If exoticToPrim is not undefined, then
a) Let result be Call(exoticToPrim, input, «hint»).
b) ReturnIfAbrupt(result).
c) If Type(result) is not Object, return result.
d) Throw a TypeError exception.
If hint is "default", let hint be "number".
Return OrdinaryToPrimitive(input,hint).
The allowed values for hint are "default", "number", and "string". Date objects, are unique among built-in ECMAScript object in that they treat "default" as being equivalent to "string".
All other built-in ECMAScript objects treat "default" as being equivalent to "number". (ECMAScript 20.3.4.45)
So I think null converts to 0.
console.log( null > 0 ); // (1) false
console.log( null == 0 ); // (2) false
console.log( null >= 0 ); // (3) true
Mathematically, that’s strange. The last result states that "null is greater than or equal to zero", so in one of the comparisons above it must be true, but they are both false.
The reason is that an equality check == and comparisons > < >= <= work differently. Comparisons convert null to a number, treating it as 0. That’s why (3) null >= 0 is true and (1) null > 0 is false.
On the other hand, the equality check == for undefined and null is defined such that, without any conversions, they equal each other and don’t equal anything else. That’s why (2) null == 0 is false.
I had the same problem !!.
Currently my only solution is to separate.
var a = null;
var b = undefined;
if (a===0||a>0){ } //return false !work!
if (b===0||b>0){ } //return false !work!
//but
if (a>=0){ } //return true !
It looks like the way to check x >= 0 is !(x < 0) In that way make sense the response.
My code basically looks like this:
console.log(placeCost) //this returns 0 (the number, not string)
if (!placeCost || placeCost == false || placeCost == "undefined" || placeCost == '') {
console.log("no")
}
else {console.log('yes')}
Results is "no" in the console. Why does this resolve as "true"?
Try using the === operator and don't check for !var if you plan to accept falsy parameters.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness
if (placeCost === false || placeCost === "undefined" || placeCost === '') {
console.log("no")
} else {
console.log('yes')
}
You can refer to comparison operators :
Equality (==)
The equality operator == converts the operands if they are not of the
same type, then applies strict comparison.
So !placeCost (like its more verbose form : placeCost == false) is evaluated to true if placeCost is the 0 number as 0 is converted to the false value.
You want do a strict comparison ?
Use === that performs no conversion :
The identity operator returns true if the operands are strictly equal
(see above) with no type conversion.
if placeCost is 0
then !placeCost become 1, that will leads the condition is true.
if (!placeCost) // condition true when placeCost is 0
This question already has answers here:
Which equals operator (== vs ===) should be used in JavaScript comparisons?
(48 answers)
Closed 6 years ago.
When working within javascript can someone provide me a good reference or explanation over testing for equality/inequality and type coercion?
From what I have been reading I see where there are two principles of thought on using eqeq (==) vs. eqeqeq (===) some feel that you should not use eqeq and always as use eqeqeq as it is safer to use.
I have been playing around with some basic samples and I am having trouble discerning the difference or when best to use one over the other:
For example: here is some basic script I was writing out. When I test using eqeq or eqeqeq I get the same result. I have not seen an example yet where I would get a different results (ie. using eqeq returns true where eqeqeq returns false).
function write(message){
document.getElementById('message').innerHTML += message +'<br/>';
}
var tim = { name: "tim" };
var tim2 = { name: "tim" };
//objects are equal to themselves ( == vs ==== eqeq or eqeqeq)
write("tim eq tim: " + (tim == tim)); //returns true
//objects are only equal to themselves regardless of containing value got that
write("tim eq tim2: " + (tim === tim2)); //returns false
//access the primative type to test true or false
write("tim value eq tim2 value: " + (tim.name === tim2.name)); //returns true
//how does this differ in efficency over the eqeq operator? is one safer to use over the other?
//write("tim value eq tim2 value: " + (tim.name == tim2.name)); //also returns true
//testing primatives
write("apple eqeqeq apple: " + ("apple" === "apple")); //true
write("apple eqeqeq apple: " + ("apple" == "apple")); //true
Can someone provide an explanation or reference I can read that helps clarify this a bit more.
cheers,
The difference between == and === is fairly simple: == is a comparison of value. === is a comparison of value and type. Using === will prevent JavaScript from dynamically determining type and compares values exactly as they are.
5 == "5" //true - JS compares the number 5 to a string of "5" and determines the contents are the same
5 === "5" //false - A character is not a number, they can't be the same.
0 == false //true - false is a bool, 0 is numerical, but JS determines that 0 evaluates to false
0 === false //false - numeric is not boolean, they can't be exactly the same thing
5 == 5.0 //true - need I say more?
5 === 5.0 //true - one is a float and one is an int, but JS treats them all as numerical
I find it's critical for tests with functions that can return both false (for failure) and 0 (as a legitimate result).
JS has a total of 5 primitive types = numerical, string, boolean, null and undefined. === requires both arguments to be of the same type and equal value to return true. There are no float, int, long, short, etc - any type of number is lumped together as numerical.
It is simple.
== performs a type conversion and then compares converted values to your desired value
=== doesnt perform type conversion and directly compares your values.
Obviously === is better in terms of performance and accuracy but == is also convinient in some cases so you can use them both if they suit your needs.
comparisons
Cheers!
Below is a very complete list of things that you won't expect when using equality operators
All of the following are true:
0 == ""
0 == " "
0 == []
false == ""
false == " "
false == []
[] == ""
null == undefined
"str" == ["str"]
"1" == true
"0" == false
"null" != null
"false" != false
"true" != true
"undefined" != undefined
"NaN" != NaN
NaN != NaN //exception: NO exception
{} != {} //exception: same reference
[] != [] //exception: same reference
--------------------------------------
new Number(10) !== 10
new String("str") !== "str"
NaN !== NaN //exception: NO exception
{} !== {} //exception: same reference
[] !== [] //exception: same reference
(Some of them came from this source)
In conclusion, never use ==. Not even when you want to:
"It is highly recommended to only use the strict equality operator. In
cases where types need to be coerced, it should be done explicitly and
not left to the language's complicated coercion rules."
(source)
=== is the strict equality operator which returns true only if the variables have the same type and value.
a = 1;
b = "1";
a == b will return true, a === b will return false
The rule of == is not easy to remember, can you get all the right answer of below examples?
"" == "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
So it is better only use ===, and never use ==.
You must have heard someone that javascript is very loosely typed language.
So as surreal said above
The (==) operator is used when you only want to compare the values of the arguments and do not care about their type
like 5=="5" will return true. This is the case when you want to see (for instance what key the user pressed and you don't care about the the type of it may be a string, a char or an integer).
But there me be a case when the type of arguments also matters. In such cases you want to compare the types of the operators. So in those cases you use the triple equality operator.
For example if you are performing some addition or multiplication operations then you want to make sure that the operands are of the compatible type. So you use the triple (===) operator.
I had to write a routine that increments the value of a variable by 1 if its type is number and assigns 0 to the variable if not, where the variable is initially null or undefined.
The first implementation was v >= 0 ? v += 1 : v = 0 because I thought anything not a number would make an arithmetic expression false, but it was wrong since null >= 0 is evaluated to true. Then I learned null behaves like 0 and the following expressions are all evaluated to true.
null >= 0 && null <= 0
!(null < 0 || null > 0)
null + 1 === 1
1 / null === Infinity
Math.pow(42, null) === 1
Of course, null is not 0. null == 0 is evaluated to false. This makes the seemingly tautological expression (v >= 0 && v <= 0) === (v == 0) false.
Why is null like 0, although it is not actually 0?
Your real question seem to be:
Why:
null >= 0; // true
But:
null == 0; // false
What really happens is that the Greater-than-or-equal Operator (>=), performs type coercion (ToPrimitive), with a hint type of Number, actually all the relational operators have this behavior.
null is treated in a special way by the Equals Operator (==). In a brief, it only coerces to undefined:
null == null; // true
null == undefined; // true
Value such as false, '', '0', and [] are subject to numeric type coercion, all of them coerce to zero.
You can see the inner details of this process in the The Abstract Equality Comparison Algorithm and The Abstract Relational Comparison Algorithm.
In Summary:
Relational Comparison: if both values are not type String, ToNumber is called on both. This is the same as adding a + in front, which for null coerces to 0.
Equality Comparison: only calls ToNumber on Strings, Numbers, and Booleans.
I'd like to extend the question to further improve visibility of the problem:
null >= 0; //true
null <= 0; //true
null == 0; //false
null > 0; //false
null < 0; //false
It just makes no sense. Like human languages, these things need be learned by heart.
JavaScript has both strict and type–converting comparisons
null >= 0; is true
but
(null==0)||(null>0) is false
null <= 0; is true but (null==0)||(null<0) is false
"" >= 0 is also true
For relational abstract comparisons (<= , >=), the operands are first converted to primitives, then to the same type, before comparison.
typeof null returns "object"
When type is object javascript tries to stringify the object (i.e null)
the following steps are taken (ECMAScript 2015):
If PreferredType was not passed, let hint be "default".
Else if PreferredType is hint String, let hint be "string".
Else PreferredType is hint Number, let hint be "number".
Let exoticToPrim be GetMethod(input, ##toPrimitive).
ReturnIfAbrupt(exoticToPrim).
If exoticToPrim is not undefined, then
a) Let result be Call(exoticToPrim, input, «hint»).
b) ReturnIfAbrupt(result).
c) If Type(result) is not Object, return result.
d) Throw a TypeError exception.
If hint is "default", let hint be "number".
Return OrdinaryToPrimitive(input,hint).
The allowed values for hint are "default", "number", and "string". Date objects, are unique among built-in ECMAScript object in that they treat "default" as being equivalent to "string".
All other built-in ECMAScript objects treat "default" as being equivalent to "number". (ECMAScript 20.3.4.45)
So I think null converts to 0.
console.log( null > 0 ); // (1) false
console.log( null == 0 ); // (2) false
console.log( null >= 0 ); // (3) true
Mathematically, that’s strange. The last result states that "null is greater than or equal to zero", so in one of the comparisons above it must be true, but they are both false.
The reason is that an equality check == and comparisons > < >= <= work differently. Comparisons convert null to a number, treating it as 0. That’s why (3) null >= 0 is true and (1) null > 0 is false.
On the other hand, the equality check == for undefined and null is defined such that, without any conversions, they equal each other and don’t equal anything else. That’s why (2) null == 0 is false.
I had the same problem !!.
Currently my only solution is to separate.
var a = null;
var b = undefined;
if (a===0||a>0){ } //return false !work!
if (b===0||b>0){ } //return false !work!
//but
if (a>=0){ } //return true !
It looks like the way to check x >= 0 is !(x < 0) In that way make sense the response.