Qual é a razão para usar nulo em vez de indefinido em JavaScript?

Tenho escrito JavaScript há bastante tempo e nunca tive um motivo para usá-lo null. Parece que undefinedé sempre preferível e tem o mesmo propósito de maneira programática. Quais são algumas razões práticas para usar em nullvez de undefined?

Nulo e indefinido são essencialmente dois valores diferentes que significam a mesma coisa. A única diferença está nas convenções de como você os usa em seu sistema. Como alguns mencionaram, algumas pessoas usam null para significar "nenhum objeto", onde às vezes você pode obter um objeto, enquanto indefinido significa que nenhum objeto era esperado (ou que houve um erro). Meu problema com isso é completamente arbitrário e totalmente desnecessário.

Dito isso, há uma grande diferença - variáveis ​​que não são inicializadas (incluindo parâmetros de função onde nenhum argumento foi passado, entre outras coisas) são sempre indefinidas.

É por isso que em meu código nunca uso nulo, a menos que algo que não controle retorne nulo (correspondência de regex, por exemplo). A beleza disso é que simplifica muito as coisas. Nunca preciso verificar se x === indefinido || x === null. E se você tem o hábito de usar == ou simplesmente coisas como if (x) .... Pare com isso. !xserá avaliado como verdadeiro para uma string vazia, 0, nulo, NaN - ou seja, coisas que você provavelmente não deseja. Se você quiser escrever javascript que não seja horrível, sempre use triplo igual a === e nunca use nulo (use undefined ao invés). Isso tornará sua vida muito mais fácil.

Eu realmente não tenho uma resposta, mas de acordo com Nicholas C. Zakas , página 30 de seu livro " Professional JavaScript for Web Developers " :

Ao definir uma variável que deve conter posteriormente um objeto, é aconselhável inicializar a variável nullcomo ao invés de qualquer outra coisa. Dessa forma, você pode verificar explicitamente o valor nullpara determinar se a variável foi preenchida com uma referência de objeto posteriormente

No final do dia, porque nulle undefinedcoage ao mesmo valor ( Boolean(undefined) === false && Boolean(null) === false), você pode tecnicamente usar qualquer um para fazer o trabalho. No entanto, existe o caminho certo, IMO.

1. Deixe o uso de undefinedpara o compilador JavaScript.

   undefinedé usado para descrever variáveis ​​que não apontam para uma referência. É algo que o compilador JS cuidará para você. No momento da compilação, o mecanismo JS definirá o valor de todas as variáveis ​​içadas como undefined. Conforme o mecanismo avança pelo código e os valores se tornam disponíveis, o mecanismo atribuirá os respectivos valores às respectivas variáveis. Para aquelas variáveis ​​para as quais não encontrou valores, as variáveis ​​continuariam a manter uma referência à primitiva undefined.

2. Use nulo apenas se desejar denotar explicitamente o valor de uma variável como tendo "nenhum valor".

   Como @ com2gz afirma: nullé usado para definir algo vazio de forma programática. undefinedpretende dizer que a referência não existe. Um nullvalor tem uma referência definida para "nada". Se você estiver chamando uma propriedade não existente de um objeto, você obterá undefined. Se eu deixasse essa propriedade intencionalmente vazia, então deve ser nullpara que você saiba que é de propósito.

TLDR; Não use o undefinedprimitivo. É um valor que o compilador JS definirá automaticamente para você quando você declarar variáveis ​​sem atribuição ou se tentar acessar propriedades de objetos para os quais não há referência. Por outro lado, use nullse e somente se você deseja intencionalmente que uma variável "não tenha valor".

Eu nunca defini nada explicitamente como indefinido (e não encontrei isso nas muitas bases de código com as quais interagi). Além disso, raramente uso null. As únicas vezes que uso nullé quando quero denotar o valor de um argumento para uma função como sem valor, ou seja ,:

function printArguments(a,b) {
  console.log(a,b);
}

printArguments(null, " hello") // logs: null hello

indefinido é onde nenhuma noção da coisa existe; ele não tem tipo e nunca foi referenciado antes nesse escopo; null é onde se sabe que a coisa existe, mas não tem valor.

Todo mundo tem sua própria maneira de codificar e sua semântica interna, mas com o passar dos anos descobri que esse é o conselho mais intuitivo que dou às pessoas que fazem esta pergunta: na dúvida, faça o que o JavaScript faz .

Digamos que você esteja trabalhando com propriedades de objeto como opções para um plugin jQuery ... pergunte-se qual valor o JavaScript dá a uma propriedade que ainda não foi definida - a resposta é undefined. Portanto, neste contexto, eu inicializaria esses tipos de coisas com 'indefinido' para serem consistentes com JavaScript (para variáveis, você pode fazer em var myVar;vez de var myVar = undefined;).

Agora, digamos que você esteja fazendo manipulação de DOM ... que valor o JavaScript atribui a elementos inexistentes? A resposta é null. Este é o valor com o qual eu inicializaria se você estivesse criando uma variável de espaço reservado que posteriormente conterá uma referência a um elemento, fragmento de documento ou similar relacionado ao DOM.

Se você estiver trabalhando com JSON, um caso especial precisa ser feito: para valores de propriedade indefinidos, você deve configurá-los como ""ou nullporque um valor de undefinednão é considerado o formato JSON adequado.

Com isso dito, como um postador anterior expressou, se você descobrir que está inicializando coisas com nullou undefinedmais de uma vez na lua azul, então talvez você deva reconsiderar como você fará para codificar seu aplicativo.

Você pode adotar a convenção sugerida aqui, mas realmente não há um bom motivo para isso. Não é usado de forma consistente o suficiente para ser significativo.

Para tornar a convenção útil, primeiro você deve saber que a função chamada segue a convenção. Em seguida, você deve testar explicitamente o valor retornado e decidir o que fazer. Se você obtiver indefinido , pode assumir que ocorreu algum tipo de erro conhecido pela função chamada . Mas se um erro aconteceu, e a função sabia disso, e é útil enviar isso para um ambiente mais amplo, por que não usar um objeto de erro? ou seja, lançar um erro?

Portanto, no final do dia, a convenção é praticamente inútil em qualquer coisa além de programas muito pequenos em ambientes simples.

Uma propriedade útil em null que undefined não se qualifica:

> null + 3
3
> undefined + 3
NaN

Eu uso nullquando quero 'desligar' um valor numérico ou inicializar algum. Meu último uso foi manipular a transformação css:

const transforms = { perspective : null, rotateX : null };
// if already set, increase, if not, set to x
runTimeFunction((x) => { trasforms.perspective += x; });
// still useful, as setting perspective to 0 is different than turning it off
runTimeFunction2((x) => { transforms.perspective = null; });

// toCss will check for 'null' values and not set then at all
runTimeFunction3(() => { el.style.transform = toCss(transforms); });

Não tenho certeza se devo usar este pensamento de propriedade ...

Os nós e elementos DOM não são indefinidos, mas podem ser nulos.

• O nextSibling do último filho de um elemento é nulo.

• O irmão anterior do primeiro filho é nulo.

• Uma referência document.getElementById será nula se o elemento não existir no documento.

Mas em nenhum desses casos o valor é indefinido ; simplesmente não há nenhum nó ali.

Alguns disseram que não há problema em inicializar objetos para null. Eu só queria apontar que os padrões de argumento de desestruturação não funcionam null. Por exemplo:

const test = ({ name } = {}) => {
  console.log(name)
}

test() // logs undefined
test(null) // throws error

Isso requer a realização de nullverificações antes de chamar a função, o que pode acontecer com frequência.

Estou trabalhando exatamente nessa questão agora e observando a seguinte filosofia:

1. Qualquer função que se destina a retornar um resultado deve retornar nulo se não conseguir encontrar um resultado
2. Qualquer função que NÃO se destina a retornar um resultado retorna implicitamente indefinido.

Para mim, essa questão é significativa porque qualquer pessoa que chamar uma função que retorna um resultado não deve ter dúvidas sobre se deve testar indefinido versus nulo.

Esta resposta não tenta abordar:

1. Valores de propriedade de nulo vs indefinido
2. Variáveis ​​dentro de suas funções sendo nulas vs indefinidas

Na minha opinião, as variáveis ​​são da sua própria conta e não uma parte da sua API, e as propriedades em qualquer sistema OO são definidas e, portanto, devem ser definidas com valor diferente do que seriam se não fossem definidas (nulo para definido, indefinido é o que você obter ao acessar algo que não está em seu objeto).

Este é um motivo: var undefined = 1 é javascript legal, mas var null = 1é um erro de sintaxe. A diferença é que nullé uma palavra-chave do idioma, enquantoundefined , por algum motivo, não é.

Se seu código se baseia em comparações undefinedcomo se fosse uma palavra-chave ( if (foo == undefined)- um erro muito fácil de cometer), isso só funciona porque ninguém definiu uma variável com esse nome. Todo aquele código é vulnerável a alguém acidentalmente ou maliciosamente definir uma variável global com aquele nome. Claro, todos nós sabemos que definir acidentalmente uma variável global é totalmente impossível em javascript ...

Só quero acrescentar que com o uso de certas bibliotecas javascript, null e undefined podem ter consequências indesejadas.

Por exemplo, a getfunção de lodash , que aceita um valor padrão como terceiro argumento:

const user = {
  address: {
    block: null,
    unit: undefined,
  }
}
console.log(_.get(user, 'address.block', 'Default Value')) // prints null
console.log(_.get(user, 'address.unit', 'Default Value')) // prints 'Default Value'
console.log(_.get(user, 'address.postalCode', 'Default Value')) // prints 'Default Value'

Outro exemplo: se você usar defaultProps no React, se uma propriedade for passada null, os props padrão não serão usados ​​porque null é interpretado como um valor definido . por exemplo

class MyComponent extends React.Component {
   static defaultProps = {
      callback: () => {console.log('COMPONENT MOUNTED')},
   }
   componentDidMount() {
      this.props.callback();
   }
}
//in some other component
<MyComponent />   // Console WILL print "COMPONENT MOUNTED"
<MyComponent callback={null}/>   // Console will NOT print "COMPONENT MOUNTED"
<MyComponent callback={undefined}/>   // Console WILL print "COMPONENT MOUNTED"

Discordo totalmente que o uso nulo ou indefinido seja desnecessário. indefinido é a coisa que mantém vivo todo o processo de encadeamento do protótipo. Portanto, o compilador apenas com nulo não pode verificar se esta propriedade é igual a nula ou não está definida no protótipo de terminal. Em outras linguagens de tipo dinâmico (por exemplo, Python), ele lança uma exceção se você deseja acessar uma propriedade não definida, mas para linguagens baseadas em protótipo, o compilador também deve verificar os protótipos pais e aqui são os locais quando os indefinidos mais precisam.

Todo o significado de usar nulo é apenas vincular variável ou propriedade com objeto que é único e tem significado de vazio, e também uso de nulo para fins de desempenho. Este 2 código tem tempo de execução diferente.

var p1 = function(){this.value = 1};
var big_array = new Array(100000000).fill(1).map((x, index)=>{
    p = new p1();
    if(index > 50000000){
       p.x = "some_string";
    }

    return p;
});
big_array.reduce((sum, p)=> sum + p.value, 0)

var p2 = function(){this.value = 1, p.x = null};
var big_array = new Array(100000000).fill(1).map((x, index)=>{
    p = new p2();
    if(index > 50000000){
       p.x = "some_string";
    }

    return p; 
});
big_array.reduce((sum, p)=> sum + p.value, 0)

Variável desconhecida: undefined.

Variável conhecida ainda nenhum valor: null.

1. Você recebe um objeto de um servidor server_object,.
2. Você faz referência server_object.errj. Diz a você que é undefined. Isso significa que não sabe o que é.
3. Agora você faz referência server_object.err. Diz a você que é null. Isso significa que você está referenciando uma variável correta, mas ela está vazia; portanto, nenhum erro.

O problema é quando você declara o nome de uma variável sem um valor ( var hello) js declara que como undefined: esta variável não existe; enquanto os programadores geralmente querem dizer: “Eu não dei um valor ainda”, a definição de null.

Portanto, o comportamento padrão de um programador - declarar uma variável sem valor como nada - está em desacordo com js - declarando-a como não existente. Além disso, !undefinede !nullsão ambos true, a maioria dos programadores os trata como equivalentes.

Você pode, é claro, garantir que sempre o faça, var hello = nullmas a maioria não vai bagunçar seu código como tal para garantir a sanidade de tipo em uma linguagem deliberadamente fracamente tipada, quando eles e o !operador tratam ambos undefinede nullcomo equivalentes.