React Native: Como organizar seus componentes
Tags: reactnative, react, javascript, ptbr
Published: 2019-03-30 08:03:22

Pode ser bem fácil escrever código - mas como você o organiza?

Eu trabalhei com dezenas de desenvolvedores trabalhando com o React Native e vi uma variedade incrível quando o assunto é organizar o código. De colocar tudo em um arquivo para arquivos com menos de 10 linhas em média.

Neste tutorial, quero falar de uma abordagem equilibrada. Uma maneira de organizar seu código para que seja fácil trabalhar e manter, mas não é um fardo para gerenciar.

# Estrutura geral do projeto

Estamos falando apenas sobre componentes da interface do usuário neste tutorial, mas quero dar uma visão geral de como os meus projetos React Native são normalmente estruturados.

```bash
# Estrutura de diretórios do projeto
/app
  /assets
  /components
  /config
  /navigation
  /screens
  /util
  index.js
```

Não mencionado é o resto dos arquivos React Native. Eu gosto de encapsular meu código em um diretório `app` ou `src`, ficando claro o que é "meu" o tempo todo. Isso também facilita a atualização do meu projeto e reduz a probabilidade de conflitos de mesclagem.

# Minha Filosofia sobre Componentes

Antes de prosseguir quero dizer que quando estou dizendo componente, no contexto deste tutorial, quero dizer os componentes de interface do usuário do meu aplicativo. Eles normalmente lidam apenas com a apresentação de dados e, em seguida, um componente diferente (a `screen`) lidará com dados.

Por exemplo: Eu tenho uma tela de login com 3 entradas de texto e um botão. Vou estruturar isso para que os componentes de entrada de texto exibam os dados e lidem com estilo. Quando o usuário digita texto / pressiona um botão, essas entradas serão passadas para a `screen` para descobrir o que fazer com isso.

Esta é a metodologia que uso para todos os meus componentes.

# Organizando por "Área Funcional"

Conforme seu aplicativo cresce, você terá mais componentes. À medida que seus componentes crescem em complexidade, você vai querer dividi-los em partes menores, para que sejam mais fáceis de raciocinar e manter.

Como isso acontece, você pode acabar com um enorme diretório de componentes! Isso pode ser bom - mesmo no meu exemplo abaixo, eu ainda acho aceitável.

```bash
# Grande lista de componentes
/components
  TextInput.js
  Switch.js
  Button.js
  List.js
  ListItem.js
  Loading.js
  Calendar.js
  CalendarItem.js
  CardContainer.js
  CardBodyImage.js
  CardBodyText.js
  Header.js
  HeaderLeftButton.js
  HeaderCenterContent.js
  HeaderRightButton.js
  ...
```

**Mas...** pode ser difícil descobrir como todos se relacionam entre si. Imagine que você compartilhou o estilo entre os componentes do cartão, os componentes do cabeçalho, o formulário, a lista, etc. Onde você coloca essas partes compartilhadas da lógica?

É por isso que gosto de dividir os componentes em um nível mais profundo por área funcional. Vamos pegar o exemplo acima e organizá-lo um nível mais focado.

```bash
# Componentes organizados por área funcional
/components
  /Form
    TextInput.js
    Switch.js
  /List
    List.js
    ListItem.js
  /Calendar
    Calendar.js
    CalendarItem.js
  /Card
    CardContainer.js
    CardBodyImage.js
    CardBodyText.js
  /Header
    Header.js
    HeaderLeftButton.js
    HeaderCenterContent.js
    HeaderRightButton.js
  Loading.js
  Button.js
```

Adicionamos um nível de aninhamento, que ajuda a organizar os componentes por área funcional. Nós sabemos o que está relacionado em um relance.

Agora, se precisarmos de estilos compartilhados entre um conjunto de componentes, basta colocá-lo nesse diretório. Fácil.

Uma última coisa - eu gosto de fazer uma área funcional de componentes exportar uma API. Isso me permite renomear/reestruturar as coisas à vontade. Isso significa que eu adiciono um `index.js` a cada diretório que exporta os componentes.

```jsx
// Form/index.js

import TextInput from './TextInput.js';
import Switch from './Switch.js';

export { TextInput, Switch };
```

Outro benefício disso é que minhas importações de outras telas/componentes são reduzidas. Ao invés de ter que fazer:

```jsx
import TextInput from '../components/Form/TextInput';
import Switch from '../components/Form/Switch';
```

Eu posso ter uma importação como:

```jsx
import { TextInput, Switch } from '../components/Form';
```

# Evite Aninhamento Profundo

Agora, uma rápida advertência para essa abordagem. Eu recomendo à você não ir mais fundo do que isso em pastas aninhadas. Elas podem se transformar em um grande ponto de dor de cabeça!

Inconsistência causa confusão. Confusão provoca *skynet*. Não crie a _skynet_.

Aqui está um exemplo. Vamos dizer que temos um conjunto de cores padrão `config/colors.js`. Para obter isso do nosso arquivo `TextInput.js`, precisamos:

```jsx
// TextInput.js

import colors from '../../config/colors.js';
```

Até aí tudo bem. Mas se formos mais fundo, você começa a ficar com mais e mais `../../../...`.

O maior desafio disso é apenas olhar e ver quantos diretórios você tem que subir. Dois eu posso entender fácil. 3 e tenho que começar a contar.

**Desconfie** de aninhamento profundo!

# Fique Flexível

Para resumir, eu só quero lembrá-lo de ficar flexível. O que funciona para mim não funciona para você 100%. Fique flexível. Às vezes, faz sentido colocar uma área funcional em um diretório (um formulário, por exemplo). Outras vezes não há razão (como um indicador de carregamento). Mantenha-se flexível e estabeleça sistemas/regras no seu aplicativo e implemente elas!

Após um tempo, revise essas decisões. Você terá uma experiência maior e saberá porque algo não está funcionando, te deixando confortável para ir em frente e consertar.

Não gaste muito tempo se preocupando com a organização do código "perfeito". Eu garanto que você vai acabar odiando algo se você gastar 10 minutos ou 10 horas configurando tudo.

# Créditos ⭐️

- [How to Organize Your Components
](https://www.reactnativeschool.com/how-to-organize-your-components), escrito originalmente por [Spencer Carli](https://dev.to/spencercarli)