Introdução ao TypeScript (Ou TS: Uma declaração)

Eu sou uma pessoa preguiçosa.

Não no sentido ruim da palavra, de ter preguiça de fazer as coisas ou ter preguiça de aprender coisas novas, não. Eu tenho preguiça de fazer coisas que são desnecessariamente complicadas, seguindo a lei do mínimo esforço. Quero dizer, se existe um meio mais simples de fazer uma coisa, por que haveria eu escolher a maneira mais complexa?

Isso, claro, se estendeu para quando eu comecei a aprender a programar. Como a maior parte do pessoal que começou a estudar ali em 2020 e 2021, eu iniciei no front-end com JavaScript e achei incrível a facilidade que era para definir variáveis. “Não preciso me preocupar qual o tipo de dado que vai ser atribuído?” ou “Se precisar trocar o tipo do valor que vai ali dentro, tudo bem?” eram coisas que eu me perguntava e ficava com os olhos brilhando.

Tudo parecia tão simples, rápido e fácil. Aí me apresentaram o TypeScript. Imediatamente torci o nariz, claro. “Tipos estáticos? Eu vou ter que declarar o valor de cada variável? O que é isso, Java?”

A ideia de adicionar uma camada de complexidade a algo que já funcionava era completamente alienígena pra mim. Quero dizer, pra quê? Nunca ouviram falar que em time que tá ganhando não se mexe?

Mas conforme eu ia avançando nos estudos do JavaScript, algumas coisas começavam a não ser tão simples, rápidas e fáceis como eram antes.

“Por que a multiplicação dessas duas propriedades está retornando NaN? Ah, um dos parâmetros na verdade é uma string”.
“Por que esse botão tá todo achatado? Ah, eu escrevi “height” errado”.
“Cadê os cards dessa lista? Ué, como assim tá dando undefined?”

A ruína de todo programador front-end iniciante.

Aí me disseram “As coisas seriam mais fáceis pra você se usasse TypeScript, sabia?”.

Mas o que é esse negócio de TypeScript, no fim das contas?

O TypeScript é um superconjunto (ou superset, pra vocês que gostam de misturar inglês com português) do JavaScript, que adiciona tipagem e verificação estática do código.

Mas… o que isso quer dizer, de verdade? Quer dizer que, por definir os tipos das variáveis, parâmetros e retornos de funções, o TypeScript verifica o código que você escreveu, procurando bugs e erros antes mesmo de ser executado.
Um dos problemas que enfrentamos ao debugar aplicações JavaScript é que os erros só surgem quando o código é executado (por exemplo, está sendo executado no browser), e essa situação é solucionada quando usamos TypeScript.

Por exemplo, se escrevermos o seguinte código:

const user = {
  name: "Pedro",
  age: 18,
};

console.log(user.location);

O JavaScript não emitiria nenhum erro, e só veríamos o problema quando executássemos esse bloco. Agora, a mesma coisa no TypeScript retorna uma situação completamente diferente…

const user = {
  name: "Pedro",
  age: 18
};

console.log(user.location);
Property 'location' does not exist on type '{ name: string; age: number; }'.

Ou seja, no próprio editor eu tenho o retorno de que o que eu estou escrevendo produzirá um bug e deve ser corrigido. É como se tivesse um par programando comigo, e apontando onde estou errando.

Além disso, o TypeScript se integra com o Visual Studio Code (ou outras IDEs) e fornece uma assistência, sugerindo os métodos do objeto que estamos editando. Por exemplo, ao selecionar uma string, podemos ter acesso a todos os métodos de string disponíveis — evitando de ter que decorar ou ter que pesquisar a cada necessidade.

Ou seja, pra mim que sou preguiçoso, o TypeScript só oferece vantagens.

É trabalhoso no começo, até que o hábito de definir os tipos para cada elemento do código sobrepuje a vontade de deixar o código decidir os tipos por conta própria.
Mas assim que isso se torna algo natural, a detecção de erros, as sugestões dos métodos dos objetos e a experiência de escrever um código de maneira mais segura e confiável são ganhos muito maiores que as dificuldades encontradas pelo caminho.

Hoje acredito que o uso do TypeScript seja muito mais benéfico do que a flexibilidade do JavaScript.