Introdução
Encontrar uma forma de estruturar uma aplicação em React que mantenha uma boa manutenibilidade e escalabilidade, com fácil leitura pode parecer uma tarefa difícil. É possível encontrar vários conteúdos sempre de uma forma diferente de estruturar o projeto de uma forma padrão.
Diferentemente do Angular, o React é um biblioteca que dá liberdade para os desenvolvedores construírem as aplicações sem necessariamente seguir um style guide.
Com um bom tempo desenvolvendo diversas aplicações, desde simples projetos, à grandes aplicações com micro-frontends. Pude chegar a uma arquitetura que pudesse deixar os componentes bem reutilizáveis, mantendo uma boa leitura e fácil manutenção, separando bem as responsabilidades, seguindo de forma concisa os princípios do SOLID.
Arquitetura
A arquitetura de cada projeto é pautado no bom senso. A idéia é simplificar o máximo possível, sempre respeitando um padrão de arquitetura e utilizando padrões de projeto e princípios do SOLID.
Para um padrão de arquitetura simples e escalável, definimos um desenho onde seguimos alguns Design Patterns.
Segundo o desenho a arquitetura do projeto contém 4 camadas.
main: Conterá todas as camadas de view da aplicação, desde componentes (Utilizando o Atomic Design), como arquivos de contexto e rotas. Preferencialmente os arquivos .tsx estarão aqui.
common: As camadas que possam ter regras em comum para o projeto e arquivos que possam ser compartilhados em uma ou mais telas, como enums, arquivos de configurações etc.
core: Aqui contém as camadas de regra de negócio de chamadas externas. Utilizando o Factory Pattern nos serviços para facilidade de manutenção e testes. Camada como o Store para uma Arquitetura Flux caso necessário. Posso deixar com uma recomendação o uso do Zustand. E para camada de validações se preciso, pode-se utilizar os esquemas de validações. Uma biblioteca interessante para isso é o Yup.
assets: A mais opcional. Caso seja necessário, aqui podemos colocar as fontes, imagens e ícones*.*
Conclusão
Posso ressaltar que cada projeto pode exigir abordagens diferentes. Tornando dispensáveis o uso de algumas dessas camadas, porém segui-las pode evitar problemas de organização e aproveitamento de código no futuro.
Sempre é bem vindo o uso de padrões de projeto. Posso deixar como um extra, a utilização do Singleton para a configuração de suas chamadas a api. Pode-se criar uma instância de configuração em um arquivo /common/configs/api.config.ts. E usar a instância pronta com baseURL, interceptors, headers e etc, em seus services na camada de core.
Top comments (0)