Imagine que você é um dev front-end e não sabe nada de arquitetura de software. Agora, imagine que você tem uma entrevista amanhã às 7h32 e precisa absorver alguns conceitos fundamentais sobre o tema. Procurando na internet, você encontra um livro específico, mas infelizmente não tem tempo suficiente para ler (afinal, sua entrevista é amanhã às 7h32).

Se você sente que pode estar nessa situação, esse artigo (e os próximos) são para você.

Se você sente que pode estar nessa situação, esse artigo (e os próximos) são para você.

O livro que estou falando sobre é Tao Of React, do Alex Kondov.

Decidi ler o livro novamente e dar alguns palpites sobre como foi utilizar alguns conceitos dele em prod. Para isso, vou usar os tópicos para falar sobre alguns assuntos específicos, desde estrutura de pastas até tomada de decisões para libs externas e gerenciamento de estados.

Então vamos lá!

1 - Arquitetura

a princípio só organizaçåo de pastas rsrs

1.1 - O módulo common

A idéia é simples: vai reutilizar em mais de uma página do seu projeto? Joga dentro de uma pasta common. Geralmente levamos em conta componentes apenas, mas hooks, helpers, tudo que vá ser reutilizado, abstraia e jogue em common.

Por que? Pra evitar códigos duplicados, facilitar manutenção de determinados componentes e funções auxiliares.

1.2 - Absolute paths

Isso pode ser considerado uma questão "inútil", mas conforme seu projeto escala, você vai agradecer de seguir essa convenção.

Consiste em basicamente não utilizar paths por referência:

../../common/helpers/f*dase.ts

Mas sim utilizar como caminhos absolutos:

@common/helpers/f*dase.ts

Os motivos são simples: organização e facilidade na leitura. Pense que você precisou mudar a estrutura de pastas por algum motivo, utilizando um path absoluto, você mantém organizado e também deixa claro de onde determinada função ou componente está vindo.

1.3 - Envolva os componentes dentro de uma pasta

Pense que você está organizando as suas roupas, você deixa preferencialmente calças com calças, camisas com camisas e camisetas com camisetas, correto? Por que eu não faria isso com meu projeto? (além de ele não usar calças).

Ta, esquece o parágrafo de cima e vamos pensar, o que é mais fácil de entender e dar manutenção?

ou

Acredito que o porquê seja auto-explicativo.

1.4 - Route/Module

Aqui eu não vou me estender muito, apenas pense em separation of concerns, tente separar ao máximo a responsabilidade de cada módulo criado (módulo pode ser a página por exemplo). Não faz sentido você ter uma pagina home e dentro da pasta dessa página home, arquivos que são sobre a página dashboard, certo? Então é isso.

1.5 - Dependências modulares

Enfim chegamos ao ponto em que discordo do autor pela primeira vez!!!

Alex Kondov, cita a regra dos três, que basicamente é: repetir código é ok se você faz isso menos que três vezes, na terceira, aí sim, você abstrai e joga na pasta common.

Já eu, acho que a partir do momento que você usa algo do módulo x, no módulo y, ele deve ser abstraído e levado ao common. (o que garante que se você precisou usar 2x, não vai precisar usar 3? Refatore isso!!!).

1.6 - Componentes externos

Aqui é mais uma dica do que de fato um pattern, leve em conta que você usa uma lib de UI que tem o componente Button, agora pense que ele é utilizado da seguinte maneira:

<Button> nome do seu butao </Button>

Por algum motivo do além, os mantainers dessa lib de UI decidem mudar a maneira com que ele é utilizado para

<Button placeholder={"nome do seu butao"} />

Devido a isso você se vê obrigado a alterar todos os lugares que usam esse componente. Qual seria a solução? Colocar um wrapper pra esse componente, assim no momento de refatorar, você poderia mudar em somente um lugar (Ok eu usei um exemplo bem absurdo mas vocês entenderam).

Agora me despeço com um spoiler do próximo tema: Como criar um módulo de maneira eficiente? (Basicamente ele ensina o passo a passo pra tu não fazer cagada na hora de modularizar sua aplicação).

E foi isso, espero que tenham curtido a leitura, estou escrevendo como eu gostaria de ler e estou aberto a feedbacks, valeu!