Null vs. Indefinido

Free youtube vídeo sobre o assunto

JavaScript (e, por extensão, Transcrito) tem dois tipos de fundo : null e undefined. Eles são destinados a significar coisas diferentes:

• algo não foi inicializado: undefined.

• algo está atualmente indisponível:null.

acto é que terá de lidar com ambos. Curiosamente em JavaScript com ==null e undefined só são iguais entre si:

// 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

Recomendo == null para verificar tanto para o undefined ou null. Geralmente não se quer fazer uma distinção entre os dois.

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

Você também pode fazer == undefined, mas == null é mais convencional ou curtos.

uma excepção, nível raizundefined valores que discutiremos a seguir.

a verificar o nível de raiz indefinido

Lembra-te como disse que devias usar == null? Claro que sim (porque acabei de o dizer). Não o uses para coisas do nível da raiz. No modo estrito, se você usar foo e foo é indefinido você obter uma ReferenceError exceção e toda a pilha de chamadas desenrola.

você deve usar o modo estrito … e, de fato, o compilador TS irá inseri-lo para você se você usar módulos … mais sobre isso mais tarde no livro, para que você não precisa ser explícito sobre isso 🙂

Então, para verificar se uma variável está definida ou não, em nível global, você normalmente usar typeof:

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

Limite de uso explícito de indefinido

Devido a Transcrição dá-lhe a oportunidade de documentar suas estruturas separadamente a partir de valores, em vez de coisas como:

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

você deve usar um tipo de anotação:

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

estilo de Nó retornos de chamada

estilo de Nó funções de retorno de chamada (por exemplo, (err,somethingElse)=>{ /* something */ }) em geral são convocadas com err definido para null se não houver um erro. Você geralmente apenas usa uma verificação truthy para isso de qualquer maneira:

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

ao criar a sua própria APIs não há problema em usar null neste caso, por consistência. Em toda a sinceridade para suas próprias APIs você deve olhar para as promessas, nesse caso você realmente não precisa se preocupar com os valores de erro ausentes (você lidar com eles com .then vs. .catch).

não utilize indefinido como meio de denotar a validade

por exemplo, uma função horrível como esta:

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

pode ser muito melhor escrita assim:

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

JSON e serialização

O JSON padrão tem suporte para codificação null mas não undefined. Quando JSON-codificação de um objeto com um atributo que é null, o atributo será incluído com o seu valor nulo, enquanto um atributo com um undefined valor serão excluídos totalmente.

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

Como resultado, baseada em JSON de dados de suporte null valores, mas não undefined valores. Uma vez que os atributos null estão codificados, pode transmitir a intenção de limpar um atributo definindo o seu valor para null antes de codificar e transmitir o objecto para uma loja remota.

A definição dos valores dos atributos indefinidos pode poupar nos custos de armazenamento e transmissão, dado que os nomes dos atributos não serão codificados. No entanto, isto pode complicar a semântica dos valores de compensação Versus valores ausentes.

Final thoughts

TypeScript team doesn’T use null: TypeScript coding guidelines and it has no caused any problems. Douglas Crockford acha que null é uma má ideia e todos devemos usar undefined.

no entanto, as bases de código do estilo NodeJS usam nullpara argumentos de erro como padrão, pois denotaSomething is currently unavailable. Eu pessoalmente não me importo de distinguir entre os dois como a maioria dos projetos usam bibliotecas com opiniões diferentes e apenas descartam ambos com == null.