A estrutura de um projeto deve contar uma história

[tayhsn]

Com um olhar de relance devemos entender a história da estrutura de um projeto. Desenvolvedores deduzem muito sobre um projeto baseado na forma em que os arquivos são organizados. Quando o abrem pela primeira vez e vêem uma estrutura de pastas genérica que já viram dez vezes antes, não terão muitos insights sobre ele.

O conteúdo de uma aplicação deveria fornecer informação sobre o domínio ao qual está servindo. Um passar de olhos pelos módulos deveria ser o suficiente para te dizer as partes de alto nível da aplicação. Deveria te dizer se é um dashboard, um website ou um aplicativo de e-commerce.

Abrir um projeto para ver pastas nomeadas de acordo com as bibliotecas não ajuda em nada. O conhecimento sobre elas poderia ser obtido ao olhar as dependências ou examinando o código. Elas deveriam ser apenas um detalhe de implementação.

Quando digo isso, frequentemente me perguntam onde coloco a lógica específica do Redux (ou de outra biblioteca de gerenciamento de estados). Novamente, isso depende do projeto e do seu domínio. Posso colocá-la na pasta da api, já que é mais relacionada a lógica do negócio. Posso criar custom hooks para acessar e modificar os dados. Em qualquer caso, não será o aspecto mais importante do meu projeto.

Esse artigo é uma tradução livre de princípios do livro Tao of React de Alexander Kondov