Recentemente tenho trabalhado com alguns projetos com arquiteturas bem confusas, aqui quando me refiro a arquitetura eu falo sobre a estruturação das camadas de dependência da aplicação.
Sendo assim, trabalhando com umas camadas especificas, tais como, camadas de serviços, camadas de componentes (sendo dois tipos específicos), camada para suas views/pages e por fim uma camada de Store para o seu gerenciador de estados.
Vamos entender o que são essas "camadas".
Camadas de Serviços
Basicamente vai conter tudo que for responsável por serviços de requisição de serviços externos, aqui podemos configurar nosso axios, por exemplo, e todos os requests que envolvem nossa aplicação.
Camada de pages/views
Eu digo das duas formas pois ambas tem a mesma responsabilidade que é renderizar sua pagina, mas porque eu vejo view em uns projetos, page em outros e as vezes os dois?
Bom vamos partir do propósito delas existirem:
- Pages é basicamente para você colocar sua pagina quando ela estiver finalizada sem logica de requests ou manipulação de eventos, somente um componente sem estado.
- View normalmente é usada pra montar sua página, onde encontramos vários componentes, manipulação de estado, eventos e requests.
Tem quem use as duas camadas e tem quem use somente a pages, como no framework do Nextjs, que precisa ter obrigatoriamente uma pasta pages para que ele encontre as rotas de cada página criada.
Mas não se preocupe, o uso de ambas ou somente pages não estará errado.
Camadas de Componentes
Essa parte é a que mais deixa dúvidas na nossa cabeça, sempre temos a imagem da pasta components e colocamos tudo que é components lá nessa pasta, mas pare pra pensar, se você tem componentes StateLess e StateFull, faz realmente sentido ter tudo isso dentro de uma unica pasta? Leve em consideração que se você tiver um projeto com 10 páginas e cada página tem no minimo 5 componentes, estaremos trabalhando com 50 arquivos .js/.jsx/.ts/.tsx dentro de uma única pasta.
Sendo que o conceito básico do React é basicamente a componentização e a fácil manipulação deles, além de reagir ao estado.
Vamos organizar isso então:
1º Passo: A nossa organização vai partir por separar o que pode ser reaproveitado e o que não pode.
2º Passo: Na sua pasta pages crie uma pasta para essa página e dentro dela crie uma também chamada de components, dentro dessa pasta coloque somente componentes que serão usados somente por essa página (que não são reutilizáveis).
3º Passo: Na pasta de components que está no mesmo nível da pages deixe somente o que for reutilizável, por exemplo, loader, toast, modal, ...
Pronto, seguindo esses três passos temos uma boa estruturação e uma facil manipulação desses components caso a gente queira desacoplar uma página não precisaremos "caçar" os seus respectivos componentes.
Camada de Store (Gerenciamento de estados)
Bom, no mercado atual temos diversas libs que fornecem esse serviço de gerenciamento, seja< Redux-thunk, Redux-Saga, MobX, Redux-Relay, entre outros, crie uma pasta no mesmo nível de pages e components do projeto com essas configurações.
Bônus
Podemos ter também camadas para utils, que serão utilitários na sua aplicação, arquivos que fazem tratativas em algum trecho do seu projeto, por exemplo, conversão de moeda.
Podemos ter a camada de Helpers, que pode manipular Error Boundaries entre outras coisas que são para ajuda no seu projeto.
Podemos ter a camada de assets que vai ser onde vai conter suas imgs, fonts e arquivos de estilização.
Podemos ter uma camada para tratar rotas publicas e privadas, se sua aplicação necessitar.
Podemos ter uma camada para Middlewares, se sua aplicação necessitar.
Mas sempre se lembre de não deixar suas camadas com dependência direta de outra camada.
Basicamente esse será nosso resultado final:
Top comments (1)
Parabéns rapaz seu post me ajudou a definir uma arquitetura simples, limpar e eficiente.