Em nossa pesquisa de desenvolvimento de 2019, perguntamos que tipo de conteúdo os usuários do Avance Network gostariam de ver além das perguntas e respostas. A resposta mais popular foi “artigos de tecnologia escritos por outros desenvolvedores”. Portanto, de agora em diante, publicaremos regularmente artigos de colaboradores. Se você tiver uma ideia e quiser enviar um argumento de venda, envie uma mensagem.

Não vejo gente suficiente falando sobre maneiras práticas de melhorar o JavaScript. Aqui estão alguns dos principais métodos que uso para escrever um JS melhor.

 

Use TypeScript

 

A primeira coisa que você pode fazer para melhorar seu JS é não escrever JS. Para os não iniciados, TypeScript (TS) é um superconjunto “compilado” de JS (qualquer coisa que seja executada em JS é executada em TS). TS adiciona um sistema de digitação opcional abrangente em cima da experiência JS vanilla. Por muito tempo, o suporte de TS em todo o ecossistema era inconsistente o suficiente para que eu me sentisse desconfortável em recomendá-lo. Felizmente, esses dias estão muito atrás de nós e a maioria dos frameworks oferece suporte a TS fora da caixa. Agora que estamos todos na mesma página sobre o que é TS , vamos falar sobre por que você gostaria de usá-lo.

 

TypeScript impõe segurança de tipo

 

A segurança de tipo descreve um processo em que um compilador verifica se todos os tipos estão sendo usados ​​de maneira legal em todo o código. Em outras palavras, se você criar uma função fooque recebe um número:

 

function foo(someNum: number): number {

 

return someNum + 5;

 

}

 

Essa foofunção deve ser sempre chamada com um número:

 

Boa

 

console.log(foo(2)); // prints “7”

 

nada de bom

 

console.log(foo(“two”)); // invalid TS code

 

Além da sobrecarga de adicionar tipos ao seu código, não há desvantagens na aplicação de segurança de tipo. O benefício, por outro lado, é grande demais para ser ignorado. A segurança de tipo fornece um nível extra de proteção contra erros / bugs comuns, o que é uma bênção para uma linguagem sem lei como JS.

 

Tipos de texto datilografado tornam possível a refatoração de aplicativos maiores

 

Refatorar um grande aplicativo JS pode ser um verdadeiro pesadelo. Grande parte da dor de refatorar JS se deve ao fato de que ele não impõe assinaturas de função. Isso significa que uma função JS nunca pode ser mal utilizada. Por exemplo, se eu tiver uma função myAPIque é usada por 1000 serviços diferentes:

 

function myAPI(someNum, someString) {

 

if (someNum 0) {

 

leakCredentials();

 

} else {

 

console.log(someString);

 

}

 

}

 

e eu mudo um pouco a assinatura de chamada:

 

function myAPI(someString, someNum) {

 

if (someNum 0) {

 

leakCredentials();

 

} else {

 

console.log(someString);

 

}

 

}

 

Tenho que ter 100% de certeza de que em cada lugar onde esta função é usada (milhares de lugares), eu atualizo corretamente o uso. Se eu perder um, minhas credenciais podem vazar. Aqui está o mesmo cenário com TS:

 

antes

 

function myAPITS(someNum: number, someString: string) { … }

 

depois de

 

function myAPITS(someString: string, someNum: number) { … }

 

Como você pode ver, a myAPITSfunção passou pela mesma mudança que a contraparte JavaScript. Mas, em vez de resultar em JavaScript válido, esse código resulta em TypeScript inválido, pois os milhares de lugares que ele usa agora fornecem os tipos errados. E por causa da segurança de tipo que discutimos antes, esses milhares de casos bloquearão a compilação e suas credenciais não vazarão (isso é sempre bom).

 

TypeScript torna a comunicação da arquitetura da equipe mais fácil

 

Quando o TS está configurado corretamente, será difícil escrever código sem primeiro definir suas interfaces e classes. Isso fornece uma maneira de compartilhar propostas concisas e comunicativas de arquitetura. Antes do TS, outras soluções para esse problema existiam, mas nenhuma o resolvia nativamente sem obrigar você a fazer um trabalho extra. Por exemplo, se eu quiser propor um novo Requesttipo para meu back-end, posso enviar o seguinte a um colega de equipe usando TS.

 

interface BasicRequest {

 

body: Buffer;

 

headers: { [header: string]: string | string[] | undefined; };

 

secret: Shhh;

 

}

 

Já tive que escrever o código, mas agora posso compartilhar meu progresso incremental e obter feedback sem investir mais tempo. Não sei se o TS é inerentemente menos sujeito a bugs do que o JS. Eu realmente acredito que forçar os desenvolvedores a definir interfaces e APIs primeiro resulta em um código melhor.

No geral, o TS evoluiu para uma alternativa madura e mais previsível ao vanilla JS. Definitivamente, os desenvolvedores ainda precisam se sentir confortáveis ​​com o JS vanilla, mas a maioria dos novos projetos que inicio hoje em dia são TS desde o início.

 

Use recursos modernos

 

JavaScript é uma das linguagens de programação mais populares (se não a mais) do mundo. Você pode esperar que uma linguagem com mais de 20 anos, usada por centenas de milhões de pessoas, já seja quase totalmente descoberta agora, mas o oposto é realmente verdadeiro. Nos últimos tempos, muitas mudanças e adições foram feitas ao JS (sim, eu sei, tecnicamente ECMAScript), fundamentalmente transformando a experiência do desenvolvedor. Como alguém que só começou a escrever JS nos últimos dois anos, tive a vantagem de entrar sem preconceitos ou expectativas. Isso resultou em escolhas muito mais pragmáticas sobre quais recursos da linguagem utilizar e quais evitar.

 

async e await

 

Por muito tempo, callbacks assíncronos baseados em eventos foram uma parte inevitável do desenvolvimento de JS:

 

retorno de chamada tradicional

 

makeHttpRequest(‘google.com’, function (err, result) {

 

if (err) {

 

console.log(‘Oh boy, an error’);

 

} else {

 

console.log(result);

 

}

 

});

 

Não vou perder tempo explicando por que o acima exposto é problemático ( mas já fiz isso antes ). Para resolver o problema com