Metodologia BEM – CSS

“To BEM or not to BEM”, eis a questão?! Certamente disse William Shakespeare numa tarde de trabalho quando abriu o Visual Code.

Desde há uns anos para cá que continua a não haver uma metodologia no mercado quando o assunto é a escrita de CSS e cada programador web tem a sua visão e nomenclatura. Dar nome a coisas sempre foi uma tarefa complicada no mundo da programação e no CSS não é excepção.

Muitos programadores não tomam a devida atenção à nomenclatura da sua sintaxe e escrevem-na sem qualquer regra, ordem ou lógica. A razão pela qual o fazemos é por não haver tempo para se pensar que nome se deve dar a cada class e acabamos por dar nomes quase aleatórios onde passados alguns meses quando se volta ao projecto perguntamo-nos “Como é que eu escrevi este código?”.

A maneira como nos organizamos, sozinhos, em equipa, em projectos remotos tem um grande impacto no hoje mas acima de tudo no amanhã e para isso surgiu o BEM.

O que é o BEM?

BEM é uma metodologia que dá visibilidade à hierarquia de um componente que pode ser constituído por um bloco, elemento e um modificador. Devemos pensar de uma maneira mais abstracta. E permite que qualquer elemento da nossa equipa seja front end ou back em qualquer lugar no mundo consiga interpretar que tipo de elemento falamos.

Só de olhar para o nome de uma class, temos rapidamente interpretar onde ela está no layout, que elementos são afectados isto mesmo quando o projecto não é nosso ou estamos simplesmente a fazer code review. Se seguido adequadamente, é muito fácil criar uma árvore DOM limpa e bem estruturada usando o BEM.

O BEM vem deixar a nu muitas lacunas nos projectos mal estruturados e obriga-nos a pensar no futuro, obriga-nos a pensar flexível, obriga-nos a pensar abstracto porque a longo prazo código de má qualidade vai consumir muito mais tempo de desenvolvimento e indirectamente ao projecto onde estamos alocados.

Devemos evitar ao máximo ser muito profundo no nesting de um componente, sendo que a minha recomendação é ir até ao nível de pai e filho, ou seja apenas 2 níveis para também não complicar na escrita e leitura do nosso código..

Depois de assimilada a técnica de BEM, podem também aplicar a usar noutras linguagens como o Javascript, Reactive, Vue.js que funciona através de componentes e módulos.

Como aplicar?

Bloco – Um bloco é totalmente independente, reutilizável ao longo do projecto e podem viver por si.

Elemento – Um elemento é escrito com dois underscores juntos sendo que pertence sempre a um bloco e não vive por si.

Modificador – Os modificadores são escrito com dois hifens depois do bloco ou do elemento. São usados para mudar o comportamento default do objecto como por exemplo cor, o tamanho, visibilidade ou estado.

Exemplos de escrita CSS com BEM:
.bloco {}
.bloco__elemento {}
.bloco--modificador {}
.bloco__elemento--modificador {}

Vantagens

  • Rápida integração de novos membros no projecto
  • Evita repetição do nome de class´s
  • CSS é independente do HTML
  • Rapidez no debug
  • Altamente Reutilizável

Desvantagens

  • Poluição visual com o tamanho das tags no HTML e CSS
  • Se a estrutura de HTML mudar, podemos ser obrigados a fazer um refactor
  • Complicado de usar correctamente

SASS e LESS

Em 2015 escrevi um artigo sobre Pré-processadores e que pode dar-te a conhecer como podes melhorar e acelerar a escrita de CSS. Quando usamos pré processadores como o SASS ou o LESS podemos tirar proveito de variáveis, funções, mixins e mais importante ainda para quem usa a metodologia BEM, é o nesting. Deixo a ressalva que é demasiado periogoso o uso do @extend que pode originar a situações confusas, repetição de código e colisões de class´s

Experiência pessoal

De há uns meses para cá que tenho começado a aplicar a metodologia BEM no meu trabalho como front-end developer em Outsystems. Não considero que tive uma curva de aprendizagem muito grande ou longa mas obrigou-me a não ser preguiçoso na nomenclatura e acima de tudo a parar para pensar antes de actuar.

As grandes diferenças senti quando outros elementos da equipa trabalharam nos meus antigos projectos e rapidamente começaram a desenvolver novas funcionalidades conforme os design do Invision. Nas reuniões de passagem de contexto e olhando para o meu código CSS e os componentes fizeram sem qualquer problema a ligação onde estava cada componente e o que este representava no projecto. Graças à flexibilidade do BEM, não houve necessidade de fazer refactoring e o projecto escalou sem qualquer colisão nas class de CSS nas diversas páginas.

Numa fase final de acalmia entre projectos também foi feito code review onde foi importante estarmos todos com as mesmas boas práticas, escrevermos da mesma maneira e pensarmos em uníssono.

 

O que não falta no mercado são outras metodologias, não há uma resposta certa ou errada mas por agora BEM faz sentido no meu trabalho diário como front end. Happy coding !

Deixar um comentário