Neste artigo vou descrever uma forma de como gosto de estruturar minhas aplicações de frontend web em React.

Trata-se de uma visão de frontend conectado com as regras de negócio via APIs Rest.

About

Esta arquitetura prioriza o código Modular. Isso implica que limita o que cada parte é capaz de fazer.

Separa o código em modulos, onde cada um tem seu contexto, dentro de seu contexto a estrutura defina pode variar, sempre que necessário.

Um claro exemplo é que tal modulo pode necessitar de uma arquitetura mais próxima de uma Library, ou performar melhor se organizada de outra forma, ou talvez seja tão simples que complicar com uma grande arquitetura seja um problema.

O programador deve ser livre para resolver o problema da melhor forma possível, mas deixo claro que essa liberdade sem responsabilidade pode ocasionar problemas de formatação, cada um faz do jeito que quer, e o código se torna extremamente complexo de manter (coisa que acontece mesmo com as camadas de um MVC), onde o padrão é não ter padrão.

Dito isso, o processo de Code Review se torna bem mais importante, e a escrita de testes um requisito obrigatório. Os testes garantem que o código funciona, e servem até como documentação para outros programadores.

---

Folder Structure

Esta sessão descreve um estrutura de pastas e arquivos que prioriza testes e modularidade de responsabilidades.

Como dito acima, a estrutura pode variar, mas deve fazer sentido, não mudar por mudar. Abaixo, descreverei uma estrutura que, sempre que possível deve ser levada em consideração para novos fluxos.

A visão é que a Page seja um orquestrador de Components isso permite criar componentes ainda mais reutilizáveis, e facilita a existência de componentes menores.

O item Page deve compor Components

Por sua vez um Component deve referenciar um link para uma View e implementar qualquer chamada que a view pode precisar.

Mas acontecem casos que não seja necessário uma camada de Component para certo componente. No caso de um botão customizado. Ou seja, essa estrutura pode variar.

 ..users                          
   ..components                  
   │ ..user-list                
   │   │ .user-list.component.tsx  
   │   └ .user-list.view.tsx      
   ..pages                      
   │ └ .users.page.tsx          
   ..shared                   

Components

Essa sessão detalhe onde cada componente deve ser definido.

Page

Tudo começa aqui, este componente é a injeção de rota do Framework / Library.

Responsável por iniciar os recursos.

Deve incluir a camada de Component

Responsável por compor componentes, desta forma, também é responsável por injetar componentes dentro de componentes.

Também é responsável por lidar com comunicações entre componentes, as comunicações podem acontecer diretamente entre modulos usando eventos.

View

Implementa todo elemento de renderização de tela. Tudo que aparece em tela, reações, inputs etc.

Não deve depender de chamadas de APIs, apenas compor as lógicas de quando devem ser recarregas.

Qualquer dependencia deve ser feita através de props, e implementadas pela camada de Component.

Pode apenas compor outras Views, não deve incluir outros componentes, pois desta forma, deixa de ser um componente, já que a renderização do mesmo pode ocasionar chamadas de APIs.

É uma boa camada para aplicar Testes de componentes, pois não dependem de nenhum recurso externo, é fácil utilizar mock para construir um estado, pois tudo pode ser carregado via props.

Component

Implementação das chamadas necessárias da camada de visualização, deve compor APIs, formatar erros.

Tudo referente a formatação de dados e chamadas deve ser feito nessa camada.

Deve injetar os valores na camada de View.

Também não deve compor outros componentes, deve carregar apenas sua view relativa.

Caso a View necessite de outros componentes, deve ser carregado também via Props

Modulos podem ser comunicar com outros modulos via Eventos.

---

Tests

Foco em Tests ajuda no processo de escrita de testes.

Um dos focos está no uso da camada de view, onde sua única responsabilidade