Executando verificação de segurança...
1
Hermes
3 min de leitura ·

Organizando tipos no código : 3 estratégias para elevar seu código.

Os desenvolvedores adoram uma boa estrutura de pastas. Isso ajuda manter o código do aplicativo organizado. Os desenvolvedores de JavaScript geralmente têm uma boa ideia sobre onde colocar seu código de implementação - mas e os tipos?

Neste post, apresentarei 3 regras sobre onde colocar seus tipos no código do aplicativo. Para a maioria de vocês, espero que confirme suas intuições existentes. Para outros, isso lhe dará algumas novas ideias para experimentar.

Colocate (ou inline) tipos de uso único

Regra 1: Quando um tipo é usado em apenas um lugar , coloque-o no mesmo arquivo onde é usado.

A maioria dos aplicativos é criada a partir de funções e classes. E quando você estiver trabalhando neles, muitas vezes precisará fazer alterações em seus tipos para continuar em movimento.

O exemplo clássico em aplicativos são as props de componentes. Se você tem um componente MyComponent que leva props foo e bar, recomendo colocar seus tipos no mesmo arquivo.

// MyComponent.tsx

interface Props {
  foo: string
  bar: number
}

export const MyComponent = (props: Props) => {
  // ...
}

Outras abordagens veriam você movendo os tipos para um módulo separado:

|- src
  |- components
    |- MyComponent.tsx
    |- MyComponent.types.ts

Mas acho essa abordagem pouco intuitiva de se trabalhar. Quando estou trabalhando em MyComponent, geralmente preciso editar sua implementação e seus tipos. Tê-los em arquivos separados só torna isso mais difícil.

Quando os tipos são verdadeiramente de uso único, não tenha medo de mantê-los inline:

// MyComponent.tsx

export const MyComponent = (props: {foo: string; bar: number}) => {
  // ...
}

Muitas equipes relutam em usar tipos embutidos porque parece muito "bagunçado". Mas não pense que você sempre precisa extrair um tipo em um type ou interface separada - inlining é absolutamente bom e é muito barato refatorá-lo em um tipo separado posteriormente, se necessário.

Mover tipos compartilhados para um local compartilhado

Regra 2: Tipos que são usados em mais de um lugar devem ser movidos para um local compartilhado.

Você deve pensar em tipos em seu aplicativo como funções. Se você tiver uma função usada em vários módulos, provavelmente desejará movê-la para um local compartilhado. O mesmo vale para os tipos.

Para mim, isso geralmente significa criar um *.types.ts arquivo em um local apropriado em meu aplicativo. Se eles forem compartilhados em todo o aplicativo, eu os colocarei na src pasta.

|- src
  |- components
    |- MyComponent.tsx
  |- shared
    |- *.types.ts

Se eles forem usados apenas na components pasta, eu os colocarei lá:

|- src
  |- components-
    |- MyComponent.tsx
    |- components.types.ts

Em outras palavras, compartilho o tipo no menor número de módulos que precisam dele.

Mover tipos compartilhados em um monorepo para um pacote compartilhado

Regra 3: Tipos que são usados em mais de um pacote em um monorepo devem ser movidos para um pacote compartilhado.

Até agora, falamos sobre tipos no contexto de um único aplicativo. Mas e se você estiver trabalhando em um monorepo com vários pacotes?

Nesse caso, você deve mover tipos compartilhados para um pacote compartilhado.

|- apps
  |- app
  |- website
  |- docs
|- packages
  |- types
    |- src
      |- shared.types.ts

No exemplo acima, temos um monorepo com três apps: app, website, e docs. Também temos um pacote types que contém tipos compartilhados em todo o monorepo.

Dependendo de como seu monorepo está estruturado, a forma como este pacote é implementado pode variar.

Conclusão

Portanto, tenha em mente essas três regras:

  1. Colocate (ou inline) tipos de uso único
  2. Mover tipos compartilhados para um local compartilhado
  3. Mover tipos compartilhados em um monorepo para um pacote compartilhado

E você estará no caminho certo para uma base de código bem estruturada.

Carregando publicação patrocinada...