Estrutura de diretórios

[dougaraujos]

Galera, já vi vários artigos e recomendações sobre organização de arquivos e pastas. Gostaria de conhecer a estrutura de diretórios e arquivos CSS que estão utilizando, para disseminarmos conhecimento e experiências.

[felipefialho]

Cara, ótimo post, esse assunto me interessa muito e estou sempre fazendo melhorias na minha estrutura, pra mim é parte essencial de um projeto modular e bem desenvolvido.

Agora estou no celular, mas prometo que amanhã passo por aqui para demonstrar como estou trabalhando nesse sentido atualmente.

[DevCarlosAugusto]

Cara, eu utilizo a estrutura de pastas citada no SMACSS, acho ela muito boa e ideal. Ultimamente tenho dado uma lida no ITCSS que é bem próximo do SMACSS.

[felipefialho]

Não esqueci não, mas ta uma correria absurda nos últimos dias. Prometo que de segunda não passa :p

[bernardodiasc]

Pelo que pude ver, a organização de arquivos descrita pelo ITCSS é uma das que mais fez sentido, pois inclui o código em ordem de especificidade.

[felipefialho]

Bom, não é segunda mais, mas vamos lá.

Utilizo a seguinte estrutura, baseada em Atomic Design e modificada ao meu gosto:

• stylus
  • _core - Aqui vai as configurações padrões do projeto: helpers, variables, functions...
  • atoms - Pequenos elementos que podem ser utilizados por todo o site, crio arquivos com índice e etc, para agrupar atoms comuns. Por exemplo: form.styl, onde fica todos os atomos de formulário.
  • molecules - Bloco maior que o atom, que modifica esses pequenos elementos ou cria novos elementos reaproveitáveis, porém "maiores", aqui entra por exemplo componentes JavaScript.
  • organisms - Bloco com elementos bem marcantes na página, como header footer navbar... geralmente não se repetem e podem modificar atoms e molecules
  • widgets - Utilizamos muitos widgets nos projetos, então eles tem uma pasta especial, cada widget no seu arquivo, podendo modificar atoms e molecules
  • pages - Quando necessário, cada página tem seu arquivo especifico e pode modificar qualquer coisa.

Minha organização mudou bastante de 2014 pra cá, mas tinha escrito um post na época falando sobre o assunto, pelo menos o conceito continua bem parecido.

\o

[karlprieb]

@lfeh utilizo uma estrutura parecida, mas tenho um folder de pages-templates e uma de pages onde extendo os pages-templates.

[dougaraujos]

Interessante. Atualmente utilizo o conceito ITCSS com algumas adaptações.

@lfeh já tinha visto alguns articles, e me interesse bastante em aplicar!
1 - Como que você faz o @import de cada folder (atoms, molecules, organisms ...) ? Existe um arquivo centralizador para cada um?
2 - Onde fica o @import das helpers, para manter a especificidade?

[felipefialho]

Fala @dougaraujos !

Sim, tenho um arquivo padrão style.styl que serve de centralizador, sem segredo aqui.

Olha um exemplo

//
// Stylesheet
// --------------------------------------------------

// Core
// --------------------------------------------------

// Packages
@import 'jeet';                    // Import Jeet to Semantic Grids (http://jeet.gs/) 
@import 'rupture/index';     // Import Rupture to MediaQueries

// Functions & Helpers
@import '_core/variables';         // Variables sets 
@import '_core/helpers';           // Helpers sets
@import '_core/typography';     // Typography sets

// Normalize  
@import '_core/normalize';         // Reset elements   


// Atoms
// --------------------------------------------------

@import 'atoms/_utilies';         // Utilies
@import 'atoms/scaffolding';   // Scaffolding  
@import 'atoms/grid';              // Grid
@import 'atoms/animations';   // Animations
@import 'atoms/types';            // Types 
@import 'atoms/buttons';         // Buttons
@import 'atoms/forms';            // Forms
@import 'atoms/icons';             // Icons 


// Molecules
// --------------------------------------------------

@import 'molecules/carousel';       // .carousel
@import 'molecules/modal';          // .modal 


// Organisms
// --------------------------------------------------

@import 'organisms/header';        // .header 
@import 'organisms/footer';        // .footer   


// Widgets
// --------------------------------------------------

@import 'widgets/widget-text';     // .widget-text   


// Pages
// --------------------------------------------------

@import 'pages/home';              // .home  

Os helpers e os mixins ficam dentro de helpers.styl no _core, mas não estou mais usando @extends só mixins ;)

[dougaraujos]

@lfeh Valeu!

Muda um pouco a forma de pensar na codificação. (Algo similar que me deparei ao arquitetar os componentes numa aplicações em ReactJS). O que é excelente em organização e reaproveitamento!

1 - Agora, existem alguns estilos padrões que utilizo e não seria exatamente um normalize. São algumas preferências herdadas ao longo dos projetos. E, para acompanhar o versionamento do normalize.css, utilizo as minhas preferências em uma pasta theme, com arquivos bem similares aos atoms.
Em Atomic Design, seria melhor colocar essas preferências como atoms mesmo, ou criar um arquivo no _core ?

2 - Quando se utiliza algum plugin via node ou bower, por exemplo, qual melhor caminho para o @import ? Copiar o arquivo para widgets/ ou colocar o path relativo ao node_modules/bower_componets ?

Ainda não tive tempo de migrar para os mixins, mas em breve!

[felipefialho]

Boas perguntas!

Uma grande vantagem do Atomic Design na minha opinião é ser facilmente adaptável para qualquer metodologia ou estilo de projeto.

1. Se for preferencias de estilo padrão de elementos, etc, eu acho interessante deixar em atoms, se for reaproveitamento de mixins ou coisas que em tese, você não pode inserir diretamente no HTML, eu acho recomendável estar em _core. A única exceção é o normalize, que mesmo sendo elementos, acabo deixando no _core, já que depois que inicio o projeto, não mexo mais.
2. Eu curto pegar o CSS desse plugin e tacar dentro de outra pasta, chamo de... plugins 😄, quando necessário dou uma otimizada no código (quase nunca está do jeito que eu gostaria). Quando são plugins JavaScript que eu mesmo desenvolvi, normalmente fica em molecules. Os widgets eu uso em alguns projetos que desenvolvemos aplicações tipo o Medium, onde a pessoa pode inserir blocos de widgets e montar a própria página sabe, sabe?

Estou extremamente confortável com a organização desse jeito, fica tudo a mão e componentizado.

[jaffarc]

Já tive varios problemas com diretórios .. ate fiz um Patterns disso:
https://github.com/jaffarc/Patterns-Grunt-Project

estou atualmente dando uma melhorada mas foi uma soluçao que encontrei

[dougaraujos]

1 - Foi o que pensei. Costumo colocar no _core tudo que considero requisito mínimo.

2 - Entendi. Na arquitetura atual, utilizo um custom onde o coloco o plugin inteiro, fora da pasta css (visto que podem conter JS ou imagens também), e isso fica bem confuso para referenciar o arquivo no @import, e até para escopar as tasks --watch. E essa otimizada do código sempre acontece mesmo, não consigo só baixar e usar. Aí nem faz sentido querer seguir a versão mais recente. Por isso colocar uma pasta plugins é mais decente!

Vou implementar o Atomic Design para experimentar, e possivelmente, migrar de vez.

[leandroruel]

Boa @lfeh essa de substituir @extends por @Mixins é uma boa e é recomendado pelo próprio Harry (autor do ITCSS)

[felipefialho]

@dougaraujos Conta os resultados depois. Acho que vai curtir pra carario ;)

[fdaciuk]

@lfeh, muito legal sua estrutura =)
Só uma dica: no Stylus você pode usar globbing pattern. Então, se os arquivos puderem ser carregados independente da ordem (como no caso dos atoms, molecules, etc), dá pra importar assim:

@import 'atoms/**/*'
@import 'molecules/**/*'

Isso facilita bastante pra não precisar ficar importando cada arquivo que for criado xD

=)

[felipefialho]

Nossa @fdaciuk, é verdade, acredita que ainda não tinha pensado nisso?

Como não estou mais usando @extends, é uma ótima usar dessa forma. Valeu a dica!

[felipefialho]

Pronto, já estou usando <3

https://github.com/frontendbr/eventos/tree/skeleton/src/styl

[leandroruel]

isso ai so tem no stylus? nao tem no sass normal?

[fdaciuk]

@leandroruel nops.. tem que instalar uma gem separada pra isso funciona no SASS: https://github.com/chriseppstein/sass-globbing

[dionarodrigues]

Está sensacional essa estrutura @lfeh .

Há algum tempo eu utilizei bastante do conceito do atomic design em um projeto. No entanto, o que no começo parecia algo legal, no decorrer foi tornando essa organização bem complexa e ruim de dar manutenção.

Com isso, acabei mudando a estrutura para algo bem parecido com o que você criou, mas um pouco mais enxuta, para não correr o mesmo risco com a frustrante experiência do atomic design. Na minha estrutura eu não tenho essa parte do "atoms" separado. Eu chamo de "modules" o diretório onde mantenho os arquivos que poderiam ser "atoms" ou "molecules". E, nessa minha lógica maluca (hauahua), eu vejo se realmente vale a pena separar elementos nos mínimos detalhes, em "atoms"; ou se faço as "molecules" direto.

Mas tenho repensado essa questão a fim de desenvolver uma estrutura mais abrangente e flexível e, por isso, ando revendo a possibilidade de separar os "atoms" novamente a fim de organização.

Valeu por compartilhar seu esquema!!

[felipefialho]

Acredito que uma das principais vantagens do Atomic é ser facilmente adaptável.

Eu particularmente considero a pasta atoms essencial, lá fica todos os elementos simples que vão se repetir em vários lugares do projeto.

Mas ai depende muito do tipo de projeto que você está desenvolvendo e tal.

[leandroruel]

@fdaciuk eu usava isso aqui pra injetar os imports a medida que ia adicionando mais arquivos https://www.npmjs.com/package/gulp-inject

[helderberto]

@lfeh muito bacana sua estrutura! Adaptei um projeto hoje seguindo a mesma, e ficou bem organizado.

Obrigado por compartilhar!

[felipefialho]

Bacana @helderburato!

De lá pra cá, após me aprofundar no mundo de SPAs, mudei um pouco essa estrutura, mas acredito que ainda funcione bem para projetos "normais", gosto muito da ideia do Atomic CSS.

[helderberto]

Utilizei para criar um template WordPress, ficou muito bom para manutenção e a organização em si.

Se puder compartilhar como você esta utilizando em SPAs, seria bacana. @lfeh

[simaodeveloper]

Bom, não é segunda mais, mas vamos lá.

Utilizo a seguinte estrutura, baseada em Atomic Design e modificada ao meu gosto:

• stylus

  • _core - Aqui vai as configurações padrões do projeto: helpers, variables, functions...
  • atoms - Pequenos elementos que podem ser utilizados por todo o site, crio arquivos com índice e etc, para agrupar atoms comuns. Por exemplo: form.styl, onde fica todos os atomos de formulário.
  • molecules - Bloco maior que o atom, que modifica esses pequenos elementos ou cria novos elementos reaproveitáveis, porém "maiores", aqui entra por exemplo componentes JavaScript.
  • organisms - Bloco com elementos bem marcantes na página, como header footer navbar... geralmente não se repetem e podem modificar atoms e molecules
  • widgets - Utilizamos muitos widgets nos projetos, então eles tem uma pasta especial, cada widget no seu arquivo, podendo modificar atoms e molecules
  • pages - Quando necessário, cada página tem seu arquivo especifico e pode modificar qualquer coisa.

Minha organização mudou bastante de 2014 pra cá, mas tinha escrito um post na época falando sobre o assunto, pelo menos o conceito continua bem parecido.

\o

O link do post foi atualizado para este https://www.felipefialho.com/blog/2014/falando-em-organizacao-css

[4lessandrodev]

Encontrei esse artigo atualizado 2021

https://medium.com/rd-shipit/como-criar-componentes-react-com-uma-arquitetura-escal%C3%A1vel-usando-atomic-design-74a67aaf47e0

[evertonthepaula]

Nós estamos testando o novo design system aqui na empresa utilizando ITCSS, porque apesar do desing system ser baseado em Atomic, nós estamos pensando em uma solução baseada em componentes desacoplados(que no fim das coisa da quase na mesma), nesta implementação nós temos:

Settings: Configurações de variáveis e só.

Tools: Ferramentas como mixins.

Generic: Pouco utilizado por nós no momento, basicamente onde colocamos alguns resets e "normalize".

Base: Utilizamos para setar o default de estilo do desing system, pois se todo input tem uma borda 1px solid #000, não precisa criar uma classe .input para definir algo que deveria ser default. Aqui nós definimos tudo o que é html puro.

Objects: Definem o comportamento dos "átomos", estes componentes estão na fila para se tornarem web components, mas podem ser utilizados em projetos que não possuem este recurso. Apesar de terem o estilo fechado em seu escopo, Objects herdam características de Base. Aqui também ficam manipulação de estados, por exemplo a classe .btn tem seu estado default, a classe .btn .blue, tem seu estado alterado e definido dentro do component BTN.

Components: Manipulação de objetos de layout, digamos que vc precise criar um alinhamento para uma pagina especifica, apesar de tentarmos não utilizar este diretório as vezes ele se faz necessário, principalmente quando vamos manipular nossas classes juntamente com classes de apps legados, ou para manipular comportamentos definidos em Base, por exemplo o input search terá borda verde de 2 px em determinado contexto. Aqui nós utilizamos apenas classes css. Apesar de necessário é pouco utilizado pois priorizamos modificar estilo de elementos a partir de mudança do estado do mesmo, como vimos em Objects.

Trumps: Não utilizamos.

Sei que o nome Component e Object confundem sua função, mas por enquanto é isso aí.

Tive que corrigir porque inverti a ordem