Eduardo Rabelo

Posted on Sep 17, 2020

React e TypeScript: As Partes Boas ❤️

Comecei a usar o TypeScript com React e, depois de um tempo, aprendendo e usando eles juntos. É assim que me sinto:

https://twitter.com/tejaskumar_/status/1038372714170470400

Eu não podia acreditar o quanto meu DX melhorou. Vou deixar para vocês os principais recursos de que mais gosto, então espero que vocês se sintam animados para dar uma chance 😃!

Isenção de responsabilidade ⚠️

Esta não é uma introdução ao TypeScript para iniciantes, você precisa saber pelo menos como usar Interfaces , no entanto, no final do artigo, vou apresentar uma lista de excelentes recursos que achei muito úteis. A maneira mais rápida de obter o React + TypeScript instalado e funcionando é:

$ npx create-react-app my-app --template typescript

# ou

$ yarn create react-app my-app --template typescript

TLDR;

Prós:

Preenchimento de código e validação de tipo com definições de tipo .
Ótima comunidade e recursos de aprendizagem.

Contras:

A sintaxe do TypeScript e conceitos como Generics podem ser difíceis de entender.

Índice

IntelliSense
Declarações de tipo
Validação de tipo
Ganchos
~~As partes ruins~~ ou Trade-offs ⚖️
Recursos
Conclusão

IntelliSense

Eu uso o VSCode e um de seus melhores recursos é o IntelliSense (AKA Code Completion), o TypeScript tira proveito disso. Digamos que temos um componente List e declaramos a Interface Props, neste caso um prop labels, um array de strings:

// List.tsx
import React from 'react';

interface Props {
  labels: string[]
}

// Dizemos ao TypeScript o tipo de parâmetro
// + Object Destructuring 👇
function List({ labels }: Props): React.Element {
  return (
    <ul>
      { labels.map((label, index) => {
        <li key={index}>{label}</li>
      )}
    </ul>
  );
}

const strings = ['React', 'TypeScript', '❤️'];
<List labels={strings}/>

Com isso nós temos:

Se digitarmos labels. dentro de List, obtemos o autocompletar com métodos e atributos de Array.prototype, neste caso Array.prototype.forEach () e, em seguida, dentro da função callback, obtemos todos os métodos e atributos String.prototype, neste exemplo Array.prototype.toUpperCase () .

O VSCode é escrito em TypeScript, possui definições de tipo integradas para Native Objects e a melhor parte? Podemos declarar nossos próprios tipos, e a maioria das bibliotecas que usamos já vem com seus próprios arquivos de definição de tipo 😃!

O que nos leva ao próximo grande recurso.

Definições de tipo

A comunidade TypeScript é incrível, eles criaram um enorme repositório centralizado de arquivos de definições de tipo de alta qualidade:

https://github.com/DefinitelyTyped/DefinitelyTyped

A maioria das bibliotecas mantém seus arquivos de declaração de tipo neste repositório, e às vezes temos que instalá-los de forma independente, no site oficial podemos pesquisar e encontrar instruções para instalá-los, no caso do React, por exemplo:

$ yarn add @types/react --save-dev

Como podemos usá-los?

import React from 'react';

interface Props {
  labels: string[]
}

function List({ labels }: Props): React.Element {
  const styles: React: React.CSSProperties = {
    backgroundColor: 'blue'
  }
  // ...
}

Digamos que queremos escrever algum CSS embutido, neste caso podemos usar a definição de tipo embutida do React React.CSSProperties, ela nos mostrará um erro se escrevermos um erro de digitação backgroundKolor e obteremos o preenchimento de código para as propriedades 😁.

E também podemos ver o código-fonte para nos acostumarmos a ler e escrever tipos.

Já aprendemos como tirar proveito das definições de tipo para obter o preenchimento de código, mas agora aprenderemos outro recurso poderoso que vem com eles.

Validação de tipo

E se não passarmos no tipo de prop correto ou se não passarmos nada?

interface Props {
  labels: string[]
}

function List({ labels }: Props) {
 // ...
}

const strings = ['React', 'TypeScript', '❤️'];
const numbers: number[] = [1, 2, 3];

// 1) Passamos um array de números
<List labels={numbers} />
// 2) Não passamos nada
<List />

Em ambos os casos, obtemos um Erro 🚫:

Esses erros são claros, eles nos dizem o que é type error, onde isso declaration foi feito, se a prop é realmente necessária, e isso se aplica também às funções (embora os componentes do React sejam apenas funções 😉).

O compilador TypeScript não ficará feliz até que passemos os parâmetros corretos, isso é útil para ver possíveis bugs à frente, mesmo antes de compilar o código e verificar o navegador.

E como fica o prop-types?

Sim, podemos obter a mesma validação usando prop-types:

import React from 'react';
import PropTypes from 'prop-types';

function List({ labels }) {
  // ...
}

List.propTypes = {
  labels: PropTypes.arrayOf(PropTypes.string).isRequired
}

No entanto, como prop-types verifica nosso código durante a execução, temos que compilá-lo primeiro, ver o erro real no console e, também, essa validação só acontece no modo de desenvolvimento 😟, enquanto o TypeScript analisa nosso código estaticamente.

Hooks

Quando se trata de React Hooks , useStatepor exemplo, o TypeScript pode ser muito útil, especialmente com validações de tipo.

function Counter() {
  // usamos a sintaxe <> para declarar o tipo
  const [counter, setCounter] = useState<number>(0);
  const add = () => {
    // isso irá retornar um erro 😱
    setCounter('string');
  }
  return(
    <div>
      <button onClick={add}>+</button>
      {counter}
    </div>
  );
}

Dessa forma, garantimos que sempre que atualizamos o state, o tipo de valor será correto, isso pode nos poupar horas de depuração e dores de cabeça.

As partes ruins. 🤐 Trade-offs

Aprendemos como o TypeScript pode beneficiar toda a equipe quando se trata de escrever componentes, vamos imaginar que escrevemos nossa (idealmente) biblioteca de componentes reutilizáveis com tipos bem definidos e nosso colega importa um deles, eles verão de antemão:

Tipos de props e se são necessários ou não.
Autocompletar do código para nomes de prop.

Isso pode nos poupar tempo ao navegar pelo código-fonte para garantir que passamos os dados corretos para cada componente.

Mas também sabemos que em Desenvolvimento de Software não existe bala de prata. Cada ferramenta que escolhemos vem com uma compensação, no caso do TypeScript, é claro que existem algumas:

Ler TypeScript pode ser difícil:

interface Array<T> {
  concat(...items: Array<T[] | T>): T[];
  reduce<U>(
    callback: (state: U, element: T, index: number, array: T[]) => U,
    firstState?: U
  ): U;
  // ···
}

Mas não se preocupe, eu peguei este trecho deste ótimo artigo que explica todos os detalhes, aquele exemplo foi realmente confuso para mim no início.

Alguns conceitos podem ser complicados de entender:

Interfaces
Genéricos
Interfaces vs Tipos

Esses novos conceitos (especialmente se os membros de nossa equipe não estão acostumados com eles) podem trazer mais dúvidas e confusão.

Claro que podemos enfrentá-los, depende apenas da experiência dos membros da nossa equipe, do tempo disponível e do desejo de aprender coisas novas.

Este artigo reflete a ideia que venho pensando há algum tempo e é provável que seja o meu próximo tópico de postagem everything in Software Development is a trade-off.

Recursos

Estes são os melhores recursos que me ajudaram a entender e amar o TypeScript:

Conclusão

O TypeScript vem com muitos benefícios e restrições, mas nosso contexto (equipe, prioridades, objetivos) pode definir se podemos obter mais vantagens do que desvantagens e tornar nossas vidas mais fáceis!

Quando se trata de aplicativos de grande escala, e especialmente se estivermos construindo uma arquitetura à prova de balas ou Design de Sistema, o esforço compensa, podemos escrever código menos sujeito a bugs e fornecer recursos mais rápidos e seguros.

Obrigado pela leitura, se você achou este artigo útil, siga-me no Twitter e me diga o que você achou!

Boa codificação!

Créditos

# React + TypeScript ❤️: The good parts ⚡, escrito originalmente por Diego Maximiliano.

Adição do tradutor: Aqui listo alguns artigos e traduções de minha autoria que podem te ajudar na sua jornada no TypeScript:

DEV Community