Underscore: _.isEmpty Behavior en números

Creado en 13 ene. 2012  ·  13Comentarios  ·  Fuente: jashkenas/underscore

var cow = {a: 1, b: {}, c: []};
_.isEmpty(cow); // returns false

isEmpty funciona bien en objetos que contienen números como los únicos valores 'no vacíos'

_.isEmpty(cow.a); // returns true

Sin embargo, el individuo k, v de a: 1 se considera vacío.

Leí los problemas y noté que originalmente _.isEmpty no estaba destinado a cadenas, por lo que podría serlo. Si no está previsto, entonces tengo una rama para la que puedo hacer una solicitud de extracción.

question

Comentario más útil

Bueno, sí. Me alegro que hayas preguntado :-)

La forma en que he visto a la mayoría de la gente usar _.isEmpty es más o menos para verificar si se ha asignado un valor (cualquier valor) a una variable en particular. He visto a muchos desarrolladores tener problemas debido a esto.

Incluso la documentación oficial dice "Devuelve verdadero si el objeto no contiene valores", y un número debe calificar como valor.

Si hay algún tipo de implicación mayor al hacer este cambio que simplemente no puedo ver, entonces mi segunda mejor sugerencia sería actualizar la documentación para indicar claramente que no debe usarse para números :-)

Todos 13 comentarios

El caso de uso que encontré fue hacer algo como esto

_.each(cow, function(v, k) {
  if (_.isEmpty(v)) {
    // do something with k because of v being empty
  }
});

Entonces, vaca.a sería tratada como vaca.by vaca.c. Puedo codificarlo, pero pensé que sería mucho más ordenado si no tuviera que hacerlo (y si no rompía el espíritu o la visión del guión bajo)

Sí, _.isEmpty solo se define para objetos y matrices. No debes usarlo en cadenas o números.

Entonces, ¿qué alternativas tenemos para usar con los números?

@jashkenas o @michaelficarra : ¿alguna razón en particular por la que _.isNumber no se llame en _.isEmpty ? (de la misma manera se están usando _.isArray y _.isString )

¿Alguna razón por la que debería?

Bueno, sí. Me alegro que hayas preguntado :-)

La forma en que he visto a la mayoría de la gente usar _.isEmpty es más o menos para verificar si se ha asignado un valor (cualquier valor) a una variable en particular. He visto a muchos desarrolladores tener problemas debido a esto.

Incluso la documentación oficial dice "Devuelve verdadero si el objeto no contiene valores", y un número debe calificar como valor.

Si hay algún tipo de implicación mayor al hacer este cambio que simplemente no puedo ver, entonces mi segunda mejor sugerencia sería actualizar la documentación para indicar claramente que no debe usarse para números :-)

¿Por qué querría pasar un número a isEmpty , en lugar de simplemente verificar si el número es nulo?

Incluso la documentación oficial dice "Devuelve verdadero si el objeto no contiene valores"

Muy bien. En JavaScript, un número (muy tristemente) no es un objeto.

Creo que esto podría aclararse con ajustes de _.isEmpty doc. Lo que buscan los desarrolladores es _.exists .

Tiene sentido que _.isEmpty(a) signifique "¿es a un objeto vacío?", Como si la declaración: if obj == {} funcionara en valores y no en referencias. Por lo tanto, valores como los números devolverían falsos y, por lo tanto, serían nulos e indefinidos.

una implementación de ejemplo de _.isEmpty podría ser:

_.isEmpty = function(a) {
  return _.isEqual(a, {}) || _.isEqual(a, []) || _.isEqual(a, '');
}

@jashkenas Eso es probablemente porque en algunos otros lenguajes "vacío" determina si la variable está vacía o no :) http://www.php.net/manual/en/function.empty.php

+1 a @josser , principalmente porque tengo experiencia en PHP :-p
Pero creo que solo con aclararlo en la documentación también podría ser suficiente. En serio, veo que la gente se encuentra con esto cada dos semanas.

Me encontré con esto hoy ... Lo estaba usando con _.omit

_.omit(someObject, _.isEmpty);
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

afranioce picture afranioce  ·  8Comentarios

Francefire picture Francefire  ·  5Comentarios

acl0056 picture acl0056  ·  5Comentarios

haggholm picture haggholm  ·  8Comentarios

jezen picture jezen  ·  8Comentarios