Refactoring: Organização do código

[henriquepw]

Proposta

Venho aqui propor uma nova estrutura de pastas/códigos para essa aplicação visando uma melhor organização, mais intuitiva, usando boas práticas de clean code. Se gostarem, eu mesmo faço a mudança, aproveitar que a aplicação está pequena e da pra fazer essa mudança.

Estrutura

Pastas:

• public/ -> pasta com o template da aplicação.
• src/ -> o código em si.
  • src/components/ -> pequenos componentes que fazem parte das páginas.
  • src/pages/ -> páginas da aplicação.
  • src/config/ -> configurações específicas, exemplo do Reactotron.

Libs:

• styles-components -> usar css dentro do js da uma flexibilidade muito boa, e da para usar a sintax do Sass.
• babel-plugin-root-import -> poder usar "~" nas importações sendo equivalente ao src/, evitando aquelas sequências de pontos ("../../../").
• reactotron -> aplicativo que ajuda na parte de debugging.

Código:

• usar react-hooks ao invés de classes.
• diminuir o uso excessivo de divs e usar tags mais específicas, isso é muito importante para acessibilidade. aqui um pouco sobre.

[thayannevls]

Opa henry, desculpa não tinha visto a issue.

Queria que @JoseRenan pq ele que fez a estrutura atual

[JoseRenan]

Iaeee, @henry-ns. Sobre a estrutura das pastas, eu e @JRobsonJr temos uma experiencia ruim com essa divisão de diretórios com o musicritic, a gente usava uma bem parecida e na medida que o projeto crescia, ficava muito componente espalhado no root da pasta /components e dificultava pra achar as coisas em desenvolvimento, principalmente pq os arquivos de componentes sempre se chamavam index.js, daí o que a gente fez foi tentar agrupar mais coisa nas pastas de componentes de página, tipo, na página principal do IssueAi tem o componente RepositoryList e Repository que só são usados lá, daí eles ficariam dentro da pasta da página principal, pra facilitar a busca mesmo. Btw, isso é uma sugestão pra essa nova estrutura que tu propos, eu concordo que temos de organizar as coisas por aqui mesmo!!!

[JoseRenan]

Sobre os hooks e divs, eu super apoio tbm, inclusive, no glossário @fanny já fez uma reorganização pra remover alguns divs desnecessários e deixar o HTML mais semantico.

Um bom ponto pra iniciar seria a gente listar em uma issue os pontos que precisam ser modificados (tanto pra hooks quanto os componentes com más práticas de HTML) e fazer aos poucos, ponto a ponto, até pra se outras pessoas quiserem contribuir também, paralelizar o refactoring, o que acham, @henry-ns e @thayannevls ???

[JoseRenan]

fazer aos poucos, ponto a ponto, até pra se outras pessoas quiserem contribuir também

E também pra facilitar o review kkkkkkkk 😄

[thayannevls]

acho uma boa a gente fazer isso de listar em uma issue. Era bom a gnt fzr até uma lista de features novas tbm

[thayannevls]

@henry-ns tu ainda tem interesse nessa issue?

[henriquepw]

@henry-ns tu ainda tem interesse nessa issue?

oi @thayannevls, é que apareceu muita coisa pra mim do nada ai eu dei uma afastada.

sobre o que @JoseRenan falou, eu concordo com metade do que foi dito kkk, sobre agrupar mais coisa nas pastas de componentes de página eu estou fazendo isso também, eu só boto o componente no /components se ele for usado em mais de um local e os componentes de páginas por serem algo maior eu deixo fora do /components, em uma pasta /pages fazendo assim diminui o problema de entupir o /components de coisas.

sobre dificultava pra achar as coisas em desenvolvimento, principalmente pq os arquivos de componentes sempre se chamavam index.js eu não enfrento isso porque a pasta que ele está seria o nome dele mas, isso não interfere muito, só deixa os imports mais bonitinhos.

[joaopslins]

+1 pra styled-components

Seria bacana criar uma issue pra cada seção desse refactor.