{"componentChunkName":"component---src-templates-docs-js","path":"/docs/faq-structure.html","result":{"data":{"markdownRemark":{"html":"\n

O React não opina sobre como você deve estruturar o projeto. Dito isso, existem algumas abordagens populares que você pode experimentar.

\n

Agrupar por funcionalidades ou rotas

\n

Uma maneira bem comum para estruturar os projetos é colocar CSS, JS e testes juntos dentro de pastas agrupadas por funcionalidades ou rotas.

\n
common/\n  Avatar.js\n  Avatar.css\n  APIUtils.js\n  APIUtils.test.js\nfeed/\n  index.js\n  Feed.js\n  Feed.css\n  FeedStory.js\n  FeedStory.test.js\n  FeedAPI.js\nprofile/\n  index.js\n  Profile.js\n  ProfileHeader.js\n  ProfileHeader.css\n  ProfileAPI.js
\n

A definição de “funcionalidade” não é universal e cabe a você escolher a granularidade. Se você não conseguir criar uma lista de pastas de alto nível, você pode perguntar para os usuários do seu produto quais são as partes principais que ele contém e usar o modelo mental como um plano.

\n

Agrupar por tipo de arquivo

\n

Outra maneira popular de estruturar projetos é agrupar arquivos semelhantes pelo tipo, por exemplo:

\n
api/\n  APIUtils.js\n  APIUtils.test.js\n  ProfileAPI.js\n  UserAPI.js\ncomponents/\n  Avatar.js\n  Avatar.css\n  Feed.js\n  Feed.css\n  FeedStory.js\n  FeedStory.test.js\n  Profile.js\n  ProfileHeader.js\n  ProfileHeader.css
\n

Algumas pessoas também preferem ir além, e separar os componentes em pastas diferentes, dependendo do papel que desempenham na aplicação. Por exemplo o Atomic Design que é uma metodologia de design construída sobre este princípio. Lembre-se de que é mais produtivo tratar essas metodologias como exemplos úteis, ao invés de seguir regras estritas.

\n

Evite muito aninhamento

\n

Há diversos pontos problemáticos associados ao aninhamento de pastas em projetos JavaScript. Torna-se mais difícil gravar importações relativas entre elas ou atualizá-las quando os arquivos são movidos. A menos que você tenha um motivo muito convincente para usar uma estrutura de pastas aninhadas, considere limitar-se a um máximo de três ou quatro pastas aninhadas em um único projeto. Claro, isso é apenas uma recomendação e pode não ser relevante para o seu projeto.

\n

Não pense muito

\n

Se você está apenas começando um projeto, não gaste mais do que cinco minutos na escolha de uma estrutura de arquivos. Escolha qualquer uma das abordagens acima (ou crie as suas próprias) e comece a escrever o código! Você provavelmente vai querer repensá-lo de qualquer jeito depois de ter escrito algum código.

\n

Se você se sentir completamente preso, comece mantendo todos os arquivos em uma única pasta. Eventualmente ele crescerá o suficiente para que você deseje separar alguns arquivos dos demais. A essa altura, você terá conhecimento suficiente para saber quais arquivos são modificados juntos com mais frequência. Em geral é uma boa ideia manter os arquivos que geralmente mudam juntos uns dos outros. Este princípio é chamado de “colocation”.

\n

À medida que os projetos vão crescendo, eles costumam usar uma mistura de ambas as abordagens acima na prática. Então escolher a abordagem “certa” no começo não é muito importante.

","frontmatter":{"title":"Estrutura de arquivos","next":null,"prev":null},"fields":{"path":"content/docs/faq-structure.md","slug":"docs/faq-structure.html"}}},"pageContext":{"slug":"docs/faq-structure.html"}},"staticQueryHashes":[]}