TypeScript para iniciantes: 7 erros fatais e como evitá-los

Treinador Online de Python para Iniciantes

Aprenda Python facilmente sem sobrecarga teórica. Resolva tarefas práticas com verificação automática e escreva código diretamente no navegador.

Start Course

Introdução: por que o TypeScript morde os iniciantes, ou como não fracassar no primeiro projeto

\n\n

Você já sentiu que o TypeScript é como um professor rigoroso que dá notas baixas por cada detalhe? Se sim — bem-vindo ao clube. Cada segundo iniciante que migra do JavaScript para o TypeScript comete os mesmos erros. E isso é normal: o TypeScript é realmente mais difícil, exige disciplina e compreensão de tipos.

\n\n

Mas há uma boa notícia: a maioria dos erros ao aprender TypeScript pode ser prevista e evitada. Neste artigo, reuni os 7 erros mais comuns que desenvolvedores iniciantes cometem. Analisaremos cada erro com exemplos de código, explicaremos por que é ruim e mostraremos como fazer corretamente.

\n\n

Se você está começando a aprender TypeScript ou já cometeu alguns erros — este artigo economizará horas de depuração e estresse. Vamos lá!

\n\n

Erro nº1: Uso descontrolado de any (a fonte de todos os males)

\n\n

O que os iniciantes fazem

\n

O erro mais comum entre quem estuda TypeScript é escrever any em todo lugar. Parece: "Ah, não especifiquei o tipo, mas o código funciona!".

\n\n
// ❌ Ruim: any destrói todo o benefício do TypeScript\nfunction processData(data: any) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\nconst result = processData({ name: "notebook", price: 500 });\n// Funciona... até você passar null\nprocessData(null); // Erro em tempo de execução!
\n\n

Por que isso é um erro

\n

any é um buraco negro do TypeScript. Quando você escreve any, está dizendo ao compilador: "Sai daqui, eu me viro". E ele sai. Você perde autocomplete, verificação de tipos e proteção contra erros bobos. O TypeScript se transforma de volta em JavaScript — com todas as suas falhas.

\n\n

Como corrigir

\n

Use tipos específicos. Se o tipo for desconhecido antecipadamente — unknown é seu amigo. Ele forçará você a verificar os dados antes de usá-los.

\n\n
// ✅ Bom: tipos específicos e unknown\nfunction processData(data: { name: string; price: number }) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\n// Ou se o tipo realmente for desconhecido:\nfunction safeProcess(data: unknown) {\n    if (typeof data === 'object' && data !== null && 'name' in data) {\n        // Agora o TypeScript sabe que data é um objeto com o campo name\n        console.log((data as { name: string }).name);\n    }\n}
\n\n

Dica: Ative a regra no-explicit-any no ESLint — ela impedirá o uso de any sem um motivo válido.

\n\n

Erro nº2: Ignorar o strict mode (ou "por que tudo funciona, mas não como esperado")

\n\n

O que os iniciantes fazem

\n

Muitos desenvolvedores iniciantes ao aprender TypeScript desativam o modo estrito no tsconfig.json ou nem o ativam. Tipo, "já serve, menos erros de compilação".

\n\n
// ❌ Ruim: strict: false\n// tsconfig.json\n{\n    "compilerOptions": {\n        "strict": false, // Erro!\n        "noImplicitAny": false,\n        "strictNullChecks": false\n    }\n}\n\n// Agora este código compila sem erros:\nfunction greet(name: string | null) {\n    console.log(name.toUpperCase()); // Potencial null!\n}\ngreet(null); // Erro em tempo de execução: Cannot read properties of null
\n\n

Por que isso é um erro

\n

Sem o modo estrito, o TypeScript perde metade de sua força. Você não recebe avisos sobre potenciais null e undefined, não verifica tipos de argumentos — e acaba pegando bugs em produção.

\n\n

Como corrigir

\n

Sempre ative strict: true. Isso ativa todas as verificações estritas de uma vez.

\n\n
// ✅ Bom: strict: true\n{\n    "compilerOptions": {\n        "strict": true,\n        "target": "ES2020",\n        "module": "ESNext"\n    }\n}\n\n// Agora o TypeScript forçará você a tratar o null:\nfunction g                

Blogs

Book Recommendations