Quanto devo usar 'let' vs 'const' no ES6?

Minha resposta aqui não é específica do javascript.

Como regra geral, em qualquer idioma que me permita fazer isso de maneira fácil, eu diria que sempre use const / final / readonly / seja lá o que for chamado em seu idioma sempre que possível. A razão é simples, é muito mais fácil raciocinar sobre o código quando está óbvio o que pode mudar e o que não pode mudar. E, além disso, em muitas linguagens você pode obter suporte de ferramenta que diz que você está fazendo algo errado quando atribui acidentalmente a uma variável que você declarou como const.

Voltar e mudar um const para um let é muito simples. E ir const por padrão faz você pensar duas vezes antes de fazer isso. E isso é em muitos casos uma coisa boa.

Quantos erros você viu que envolveram mudanças inesperadas de variáveis? Eu acho muito. Eu sei que a maioria dos bugs que vejo envolvem mudanças inesperadas de estado. Você não vai se livrar de todos esses bugs usando liberalmente const, mas você vai se livrar de muitos deles!

Além disso, muitas linguagens funcionais possuem variáveis imutáveis, onde todas as variáveis são constantes por padrão. Olhe para Erlang, por exemplo, ou F #. Codificar sem atribuição funciona perfeitamente nessas línguas e é uma das muitas razões pelas quais as pessoas adoram programação funcional. Há muito a aprender com essas linguagens sobre o gerenciamento de estado para se tornar um programador melhor.

E tudo começa com ser extremamente liberal com const! ;) São apenas mais dois caracteres para escrever em comparação com let, então vá em frente e const todas as coisas!

Tenha cuidado, porque as chaves do objeto const são mutáveis.

A partir daqui: link

object keys are not protected

considere este exemplo:

const colors = {red: "#f00"}; 
console.log(colors); // { "red": "#f00" }

colors.red = "#00f";
colors.green = "#0f0";
console.log(colors); // { "red": "#00f", "green": "#0f0" }

Mesma coisa para matrizes:

const numbers = [1, 2, 3];
console.log(numbers); // [ 1, 2, 3 ]

numbers.push(4);
console.log(numbers); // [ 1, 2, 3, 4 ]

Ainda não decidi totalmente, mas estou pensando em usar const para todos os não-array / não-objetos e usar let para objetos / matrizes.

Não se preocupe com isso. const é uma adição incrível ao JavaScript, e eu recomendo que você use todos os lugares que fizer sentido. Isso cria um código mais robusto.

Quando se trata de objetos, const protegerá sua variável da reatribuição, mas se você precisar de objetos imutáveis, precisará do método Object.freeze , veja abaixo.

const immutableOject = Object.freeze({immutableProperty: 'foo'});

const protegerá apenas da reconsignação, e o método freeze protegerá todas as propriedades imediatas. Se você precisar que todas as propriedades aninhadas sejam imutáveis também, você precisará recursivamente freeze delas.

No meu ES6 const não é sobre imutabilidade post, eu explico o que const significa exatamente de acordo com as especificações.

Com base nesses fatos objetivos, aqui está minha preferência pessoal:

[…] it makes sense to use let and const as follows in your ES6 code:

• use const by default
• only use let if rebinding (i.e. any form of reassignment) is needed
• (var shouldn’t be used in ES6)

Por mais subjetivo que seja, é um fato que isso se aproxima mais da intenção da especificação.

As pessoas que usam let por padrão geralmente tratam const variables como constantes (o que não é necessariamente, por design!). Para cada um deles, mas eu prefiro usar as coisas para o propósito pretendido, e não para algum significado inventado que as pessoas atribuem a ele com base em um mal-entendido.

Usar const apenas para constantes é como usar o HTML <aside> element apenas para conteúdo da barra lateral.

Minha abordagem pessoal, pensada para ajudar a legibilidade e compreensão do código:

let é somente para variáveis de curta duração, definidas em uma única linha e não alteradas depois. Geralmente as variáveis que estão lá apenas para diminuir a quantidade de digitação. Por exemplo:

for (let key in something) {
  /* we could use 'something[key]' for this entire block,
     but it would be too much letters and not good for the
     fingers or the eyes, so we use a radically temporary variable
  */
  let value = something[key]
  ...
}

const para todos os nomes conhecidos por serem constantes em todo o módulo. Não incluindo valores constantes locais. O value no exemplo acima, por exemplo, é constante em seu escopo e pode ser declarado com const , mas como há muitas iterações e para cada uma delas existe um valor com o mesmo nome , "valor", que poderia levar o leitor a pensar que value é sempre o mesmo. Módulos e funções são o melhor exemplo de variáveis const :

const PouchDB = require('pouchdb')
const instantiateDB = function () {}
const codes = {
  23: 'atc',
  43: 'qwx',
  77: 'oxi'
}

var para tudo o que pode ou não ser variável. Nomes que possam confundir as pessoas que leem o código, mesmo que sejam constantes localmente e não sejam adequadas para let (ou seja, não são concluídas em uma declaração direta simples), serão solicitadas para serem declaradas com var . Por exemplo:

var output = '\n'
lines.forEach(line => {
  output += '  '
  output += line.trim()
  output += '\n'
})
output += '\n---'

for (let parent in parents) {
  var definitions = {}
  definitions.name = getName(parent)
  definitions.config = {}
  definitions.parent = parent
}

Mais comentários e possíveis atualizações futuras aqui .

JavaScript é um pouco especial, pois variáveis podem ser funções e similares, mas considere em C #, Java ou outra linguagem de estilo C similar:

const public void DoSomething()

O const é ímpar, e isso porque as declarações de método nessas linguagens não podem mudar, uma vez que são compiladas em outra coisa, é o que elas fazem, não importa o que (ignorando alguns hacks horríveis que possam existir). / p>

Por que o JavaScript deve ser diferente? Portanto, não é compilado, mas isso não significa que devemos jogar fora a segurança que os compiladores podem fornecer. Usar a palavra-chave const nos dá mais segurança, o que certamente levará a aplicações mais robustas.