Me topé con un ejemplo de código que estaba usando esta comparación:
var someVar = 0;
Object.is(false, someVar); //Returns false
Sé false == 0
que será true
por eso que tenemos ===
.
¿Cómo es Object.is
diferente de ===
?
fuente
Me topé con un ejemplo de código que estaba usando esta comparación:
var someVar = 0;
Object.is(false, someVar); //Returns false
Sé false == 0
que será true
por eso que tenemos ===
.
¿Cómo es Object.is
diferente de ===
?
===
se llama operador de comparación estricta en JavaScript. Object.is
y el operador de comparación estricto se comportan exactamente igual excepto por NaN
y +0/-0
.
De MDN:
Object.is()
El método no es lo mismo que ser igual según el===
operador. El===
operador (y el==
operador también) trata los valores numéricos -0 y +0 como iguales y los trataNumber.NaN
como no iguales aNaN
.
El siguiente código resalta la diferencia entre ===
y Object.is()
.
console.log(+0 === -0); //true
console.log(Object.is(+0, -0)); //false
console.log(NaN === NaN); // false
console.log(Object.is(NaN, NaN)); //true
console.log(Number.NaN === Number.NaN); // false
console.log(Object.is(Number.NaN, Number.NaN)); // true
console.log(NaN === Number.NaN); // false
console.log(Object.is(NaN, Number.NaN)); // true
Puedes encontrar más ejemplos aquí .
Nota : Object.is
es parte de la propuesta ECMAScript 6 y aún no es ampliamente compatible (por ejemplo, no es compatible con ninguna versión de Internet Explorer o muchas versiones anteriores de otros navegadores). Sin embargo, puede usar un polyfill para navegadores que no son ES6 que se pueden encontrar en el enlace anterior.
.x
una cadena lo encajona en unString
objeto (y no un valor primitivo de cadena) y la comparación sería entre un objeto y una cadena; esto es muy sutil y es una trampa: las estadísticas evitan estos problemas, los métodos estáticos son más simples y fáciles de usar.document.createElement('div').isEqualNode(document.createElement('div')) === true
Object.is
usa el algoritmo SameValue de la especificación , mientras que===
usa el algoritmo de igualdad estricta . Una nota sobre el algoritmo de igualdad estricta señala la diferencia:Tenga en cuenta que:
NaN === NaN
es falso peroObject.is(NaN, NaN)
es cierto+0 === -0
es cierto, peroObject.is(+0, -0)
es falso-0 === +0
es cierto, peroObject.is(-0, +0)
es falsoJavaScript tiene al menos cuatro tipos de "igualdad":
==
), donde los operandos serán obligados a intentar hacerlos coincidir. Las reglas están claramente especificadas , pero no son obvias. ("" == 0
estrue
;"true" == true
esfalse
, ...).===
), donde los operandos de diferentes tipos no serán coaccionados (y no serán iguales), pero vea la nota anterior sobreNaN
cero positivo y negativo.Object.is
).SameValue
excepto+0
y-0
son iguales en lugar de diferentes (utilizado porMap
para las teclas y porArray.prototype.includes
).También hay equivalencia de objetos , que no es proporcionada por el lenguaje o el tiempo de ejecución en sí, pero generalmente se expresa como: Los objetos tienen el mismo prototipo, las mismas propiedades y sus valores de propiedad son los mismos (por alguna definición razonable de "lo mismo" )
Algoritmo SameValue :
... donde SameValueNonNumber es:
Algoritmo de igualdad estricto :
fuente
Lo anterior es la función polyfill para mostrar cómo
Object.is
funciona, para cualquier persona interesada en saber. Una referencia a You-Don't-Know-JSfuente
Resumen:
La
Object.is()
función toma 2 valores como argumentos y devuelve verdadero si los 2 valores dados son exactamente iguales, de lo contrario devolverá falso.¿Porqué necesitamos esto?
Puede pensar que ya tenemos una igualdad estricta (tipo de cheques + valor) al verificar javascript con el
===
operador, ¿por qué necesitamos esta función? Bueno, la igualdad estricta no es suficiente en algunos casos y son los siguientes:Object.is()
nos ayuda al poder comparar estos valores para ver si son similares, algo que el operador de igualdad estricta no puede hacer.fuente
En pocas palabras, son similares, pero
Object.is
son más inteligentes y precisos ...Veamos esto ...
Pero esto no es del todo correcto ya que ignora
-
y+
antes ...Ahora usamos:
Como puede ver, esto es más preciso para comparar.
También en caso de
NaN
que funcione más bien como correcto, ya que consideramosNaN
lo mismo.fuente