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.
# 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.
# 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.
# 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.
// 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:
import TextInput from '../components/Form/TextInput';
import Switch from '../components/Form/Switch';
Eu posso ter uma importação como:
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:
// 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 , escrito originalmente por Spencer Carli
Top comments (5)
Gostei do teu jeito de organizar components. Meu problema geralmente é quando eu estou lidando com estilos em CSS e nao estou utilizando css-in-js. Acabo ficando com Button.jsx, Button.css, Button.test.jsx, tudo misturado com os outros components, dai acabo preferindo criar uma pasta dedicada pra cada um dos components, e exportando o componente pelo index.js do component:
e dai no meu /screens component eu importo do mesmo jeito:
import Button from '../components/Button';
Acho que é por isso que todo mundo curte React... Nao é tao opinionado quanto outras frameworks.
Eu faço exatamente assim 😅
Oi, Eduardo.
Gostei bastante dessa forma de organização de componentes. Em meus projetos, eu utilizo o Atomic Design e tem dado bastante certo :)
atomicdesign.bradfrost.com/chapter-2/
Muito obrigado pelo conteúdo me ajudou bastante valeu
Muito bom! 👍