Null vs Indefinido

Free video en youtube sobre el tema

JavaScript (y, por extensión, de Transcripción) tiene dos tipos de fondo : null y undefined. Tienen la intención de significar diferentes cosas:

• Algo no se ha inicializado : undefined.

• Algo que no está disponible actualmente: null.

El hecho es que tendrás que lidiar con ambos. Curiosamente, en JavaScript con la etiqueta ==null y undefined sólo son iguales el uno al otro:

// Both null and undefined are only `==` to themselves and each other:
console.log(null == null); // true (of course)
console.log(undefined == undefined); // true (of course)
console.log(null == undefined); // true
// You don't have to worry about falsy values making through this check
console.log(0 == undefined); // false
console.log('' == undefined); // false
console.log(false == undefined); // false

Recomendar == null para comprobar tanto undefined o null. Generalmente no quieres hacer una distinción entre los dos.

function foo(arg: string | null | undefined) {
 if (arg != null) {
 // arg must be a string as `!=` rules out both null and undefined. 
 }
}

también puede hacer == undefined, pero == null es más convencional/más corto.

Una excepción, nivel raíz undefined valores que analizaremos a continuación.

Comprobando el nivel de raíz indefinido

¿Recuerdas cómo dije que deberías usar == null? Por supuesto que sí (porque lo acabo de decir ^). No lo uses para cosas a nivel de raíz. En modo estricto si usa foo y foono está definido, obtiene una excepción ReferenceError y toda la pila de llamadas se desenrolla.

Debe usar el modo estricto … y de hecho, el compilador TS lo insertará por usted si usa módulos … más información sobre estos más adelante en el libro para que no tenga que ser explícito al respecto 🙂

Para verificar si una variable está definida o no a nivel global, normalmente usa typeof:

if (typeof someglobal !== 'undefined') {
 // someglobal is now safe to use
 console.log(someglobal);
}

Limite el uso explícito de indefinido

Porque TypeScript le da la oportunidad de documentar sus estructuras por separado de los valores en lugar de cosas como:

function foo(){
 // if Something
 return {a:1,b:2};
 // else
 return {a:1,b:undefined};
}

debe usar una anotación de tipo:

function foo():{a:number,b?:number}{
 // if Something
 return {a:1,b:2};
 // else
 return {a:1};
}

Devoluciones de llamada de estilo de nodo

Las funciones de devolución de llamada de estilo de nodo (por ejemplo, (err,somethingElse)=>{ /* something */ }) generalmente se llaman con err establecido en null si no hay un error. Por lo general, solo usa una comprobación de veracidad para esto de todos modos:

fs.readFile('someFile', 'utf8', (err,data) => {
 if (err) {
 // do something
 } else {
 // no error
 }
});

Al crear sus propias API, está bien usar null en este caso para mayor coherencia. Con toda sinceridad para sus propias API, debe mirar las promesas, en ese caso, en realidad no necesita molestarse con los valores de error ausentes (los maneja con .then vs. .catch).

No use indefinido como medio para denotar validez

Por ejemplo, una función horrible como esta:

function toInt(str: string) {
 return str ? parseInt(str) : undefined;
}

se puede escribir mucho mejor de esta manera:

function toInt(str: string): { valid: boolean, int?: number } {
 const int = parseInt(str);
 if (isNaN(int)) {
 return { valid: false };
 }
 else {
 return { valid: true, int };
 }
}

y la serialización JSON

El JSON estándar tiene soporte para la codificación de null, pero no undefined. Cuando codifica JSON un objeto con un atributo null, el atributo se incluirá con su valor nulo, mientras que un atributo con un valor undefined se excluirá por completo.

JSON.stringify({willStay: null, willBeGone: undefined}); // {"willStay":null}

Como resultado, las bases de datos basadas en JSON pueden admitir valores nullpero no valores undefined. Dado que los atributos establecidos en null están codificados, puede transmitir la intent para borrar un atributo estableciendo su valor en null antes de codificar y transmitir el objeto a un almacén remoto.

Establecer valores de atributo en indefinido puede ahorrar en costos de almacenamiento y transmisión, ya que los nombres de atributo no se codificarán. Sin embargo, esto puede complicar la semántica de los valores de compensación frente a los valores ausentes.

Pensamientos finales

El equipo de TypeScript no utiliza null: Pautas de codificación de TypeScript y no ha causado ningún problema. Douglas Crockford piensa que null es una mala idea y todos deberíamos usar undefined.

Sin embargo, las bases de código de estilo NodeJS usan null para argumentos de error como estándar, ya que denota Something is currently unavailable. Personalmente, no me importa distinguir entre los dos, ya que la mayoría de los proyectos usan bibliotecas con opiniones diferentes y solo descartan ambos con == null.