Dicas para criar projetos front-end melhores e mais rápido - Parte 2

Essa é a segunda parte do artigo. Não deixe de ler a anterior aqui. Vou te dar uns minutinhos pra ir lá e voltar.

Pronto! E aí, gostou? Então vamos ver mais algumas dicas para a criação de projetos de front!

2) HTML

Ufa, planejamos bastante, temos uma boa noção dos estágios que vamos seguir com o desenvolvimento da nossa aplicação, e se você seguiu tudo certinho até aqui já temos até algum CSS escrito.

O próximo passo que costumo dar é construir todo o HTML de uma página sem me preocupar com a estilização. É isso mesmo que você leu: antes de colocar cor, mudar fonte, fazer coisinhas bonitas e animações, eu crio o esqueleto da página toda.

Aqui eu me preocupo basicamente com a semântica do HTML, ou seja, em usar as tags HTML que mais fazem sentido de acordo com o conteúdo.

Fazendo dessa forma eu sinto que consigo me concentrar primeiro em escrever um bom HTML sem me preocupar com estilização, o que aumenta minha chance de manter coerência interna nas decisões que tomar.

Importante dizer que nesse momento já entram as tags img, mas eu não adiciono a src delas.

Faço isso porque as imagens por padrão, sem nenhum CSS, tendem a ficar do tamanho do arquivo original delas, o que faz uma bagunça danada na nossa tela.

3) CSS

Finalmente chegou a hora do nosso site deixar de parecer um grande documento do Word!

a) Aplicando os componentes

Lembra que criamos classes utilitárias e componentes? Esse é um bom momento para aplicá-las na página toda.

Como um desses componentes era o container, isso já deixa o nosso grid do site no lugar, e evita que a gente estrague o alinhamento por descuido.

Além disso, vamos ver todas as fontes configuradas, talvez um botão já tomando forma aqui e ali.

O coração fica até quentinho.

b) Avançando um passo de cada vez

Minha abordagem, como já adiantei, é utilizar o paradigma mobile-first. O que eu fazia no começo: montava uma página inteira para celular e depois ia adaptando ela para telas maiores.

E o que acontecia: o Caio do Futuro se deparava com um código escrito pelo Caio do Passado, e nem sempre entendia muito bem: "como você fez essa seção daqui? Qual a lógica por trás desse calc, Caio do Passado? O que a classe T60 quer dizer?????".

Escrever códigos bem organizados é uma forma de mitigar esse problema. Lembre-se: um código bem escrito é um agrado para outros devs, mas também é um carinho no seu Eu do Futuro.

Mas além de escrever um código bem organizado e documentado, existe outra forma de reduzir esse problema: reduzindo a distância temporal entre o seu Eu do Passado e seu eu do Futuro.

E não, eu ainda não estou falando de viagem no tempo!

Qual é o pulo do gato aqui: eu não faço a estilização do site inteiro no mobile, para depois adaptar para desktop. Eu gosto de fazer a estilização do site seção por seção.

Sempre sigo a ordem das seções, então começo pelo header, por exemplo. Faço o header para celulares. Quando está tudo certo, antes de ir para a próxima seção, faço a responsividade do header para telas maiores, e testo aquela seção da largura de tela mínima até a máxima, para me certificar que todas as fotografia do meu filme estão funcionando.

Assim, tudo que fiz está mais fresco na memória, e fica muito mais fácil adaptar.

Além disso, eu garanto que só passo de uma seção para outra quando não tem nenhum bug na anterior. Assim, quando algum problema surge, provavelmente tem a ver com a seção na qual estou trabalhando naquele momento, em vez de ter que caçar na página toda o que ocasionou aquele overflow que atormenta a gente!

c) Padronize as suas propriedades CSS

Você provavelmente já teve que voltar em um código que escreveu e teve dificuldade em encontrar alguma informação que queria, ou entender o que estava acontecendo ali, né?

Isso acontece por conta da organização do código.

Por mais que a ordem das propriedades do CSS não faça diferença para o computador, nós não escrevemos o nosso código para máquinas, mas para outros desenvolvedores. E seres humanos gostam de padrões, lembra?

Quando estamos começando, nosso CSS sai na ordem em que escrevemos. Conforme a gente precisa, ou lembra de uma propriedade, a gente coloca no código, e elas ficam lá na ordem em que escrevemos.

Fica algo mais ou menos assim:

.card{
top: 20%;
width: 350px;
display: flex;
border: 1px solid red;
padding: 30px 20px;
position: absolute;
flex-direction: column;
justify-content: center;
width: 300px;
height: 250px;
left: 50%;
transform: translateX(-50%);
}

Esse código todo funciona, mas ele traz dois problemas: ele é um pouco complicado de ler, e ele permite que erros bobos aconteçam, como a redeclaração da propriedade width (você tinha percebido?).

Por isso é importante que a gente siga alguma padrão na hora de fazer o nosso CSS.

Muitas pessoas usam o padrão alfabético. Eu gosto de seguir um padrão que divide em propriedades de display, posicionamento, box-model, tipografia e depois uma miscelânea. Vou falar sobre isso em outro artigo, mas o mais importante é: escolha um padrão e seja coerente. Isso vai tornar seu projeto mais fácil de ler, de fazer manutenção, e evita declaração redundante de propriedades.

Crie um padrão, documente e siga em frente. Na dúvida, coloque em ordem alfabética.

Como ficaria nossa classe card em ordem alfabética:

.card{
border: 1px solid red;
display: flex;
flex-direction: column;
height: 250px;
justify-content: center;
left: 50%;
padding: 30px 20px;
position: absolute;
top: 20%;
transform: translateX(-50%);
width: 300px;

Aqui resolvemos o risco de declarar duas vezes a mesma propriedade, já que ao colocar em ordem alfabética ficaria gritante que temos duas propriedades repetidas, mas eu ainda acho que o código fica confuso de ler.

Como eu faria no meu dia-a-dia:

.card{
display: flex;
flex-direction: column;
justify-content: center;

position: absolute;
top: 20%;
left: 50%;
transform: translateX(-50%);

height: 250px;
width: 300px;
padding: 30px 20px;
border: 1px solid red;

Dessa maneira, as propriedades afins estão agrupadas, e eu consigo saber como elas trabalham em conjunto para atingir o leiaute desejado.

d) Evite usar código inútil

Essa parece óbvia, mas não é: é muito importante, até mesmo para que você atinja o domínio das linguagens com que for trabalhar, que mantenha apenas códigos que você realmente quer usar, que sabe o que estão fazendo naquela situação.

É muito comum ver códigos com várias propriedades CSS que não tem nenhuma função.

Uma div com todas as técnicas para centralizar um elemento aplicado nela, por exemplo. Dá pra ver a história por trás daquilo: o desenvolvedor back-end colocou uma propriedade, não funcionou; Colocou outra, não funcionou. No fim temos 10 declarações diferentes, e a div continua torta. (Esse relato é uma obra de ficção, qualquer semelhança com a realidade é mera coincidência. Beijo pra galera do back <3).

Ao usar somente propriedades CSS que tenham utilidade no seu projeto, seu código fica mais legível, e você fortalece seu conhecimento das ferramentas que usa.

Dica: use e abuse do DevTools. Você pode marcar e desmarcar as propriedades para ver o que acontece, e ele até mostra que propriedades estão declaradas, mas não estão sendo usadas.

e) Como nomear as suas classes?

Para finalizar o tópico do CSS, o temido momento: como vamos nomear as nossas classes?

A resposta é bem simples: tanto faz, mas seja coerente.

Existem diversas metodologias, e isso pode variar de equipe para equipe quando trabalhamos com outros devs. O importante é experimentar, e encontrar uma que faça sentido para você. A metodologia BEM é muito utilizada, e é um ótimo lugar para começar.

Eu, particularmente, uso uma adaptação dela, mas só nomeio novas classes quando estritamente necessário. Se posso resolver algo com seletores do CSS, eu não crio uma classe nova. Todas as seções do site têm uma classe específica (ou compartilhada, se forem seções-gêmeas), e a partir daí vou selecionando os elementos filhos com seletores CSS.

Uso as classes apenas quando há possível ambiguidade, como no exemplo abaixo.

header nav > ul{
   display: flex;
   justify-content: space-between;
   align-items: center;
}

header ul.menu-options{   
   position: absolute;
   top: 0;
   right: 0;

   padding: var(--fs-1);
   background-color: var(--colorMain);

   transform: translateY(-100%);
   transition: top 1s ease-in, transform 1s ease-in;
}

Nesse caso eu criei uma classe específica pois havia duas uls no meu header.

Esse código foi retirado do projeto criado durante o Challenge Front-End da Alura que aconteceu em março de 2023. Você pode conferir o projeto completo aqui.

f) Organização de arquivos e pastas

Por fim, tenha sempre seu CSS bem organizado. Eu costumo dividir ele em arquivos diferentes para cada seção, além de ter um arquivo para a estilização geral (guia de estilo, variáveis, componentes, classes utilitárias). Há quem goste de ter um arquivo separado para as media queries, mas eu prefiro que em cada arquivo eu tenha as media queries relevantes para aquela seção.

4) Bônus

Queria falar de alguns princípios que costumo seguir quando estou escrevendo código:

a) Legibilidade é mais importante que brevidade

Muitas vezes vejo pessoas felizes da vida porque conseguem juntar a declaração de várias propriedades CSS em uma única propriedade. ‘font’ por exemplo substitui outras SETE propriedades.

Usar esse artifício torna seu código mais curto, mas será que torna ele mais legível?

Sempre que me deparo com uma dessas escolhas, esse é o primeiro princípio que me vem à mente: é mais importante ter um código legível, organizado e intuitivo do que deixar de escrever algumas linhas de código para no futuro ter dificuldade de fazer manutenção no código.

Isso não quer dizer que está liberado o Ctrl + C; Ctrl + V!

“Ah, o Caio falou que legibilidade é tudo e brevidade não importa. Vou fazer um código gigantesco e redundante e vou dormir feliz”.

Intepretação de texto freestyle não se cria aqui, não. Por isso, vamos para o próximo tópico.

b) DRY (Don’t repeat yourself/Não se repita)

Sempre que no nosso código estamos copiando e colando alguma estrutura, é sinal de que poderíamos abstrair aquela estrutura para evitar a repetição.

Essa abstração pode ser na forma de uma classe ou Custom Property do CSS, ou mesmo uma variável ou função no JavaScript, depende do ambiente em que estamos.

Nesse artigo já apliquei o DRY sem nomeá-lo: quando criamos nossas classes de componentes, estávamos abstraindo propriedades CSS para uma classe, a fim de não termos que repetir aquelas propriedades várias vezes.

c) Intencionalidade e Coerência

Aqui a coisa fica meio abstrata, mas talvez seja o ponto mais importante: tenha uma razão por trás de suas escolhas, e não mude essa racionalidade no meio de um projeto.

Digamos que você está fazendo um site, e dentro de uma seção você tem três informações: título, texto e uma foto, um embaixo do outro. No figma, todos eles têm o mesmo espaçamento inferior: 24px.

Você pode construir essa tela assim. Você pode abrir em outra tela para ver melhor:

Mas isso, por mais que funcione agora na sua tela, pode trazer alguns problemas.

Como escolhemos o tamanho da fonte do h1 utilizando px e do p utilizando rem, caso haja a mudança da fonte padrão do browser a relação entre as nossas fontes vai mudar.

Pior que isso: se essa relação entre fontes mudar, como escolhemos as margin-bottom de cada um utilizando também padrões diferentes, o espaçamento inferior entre eles também vai ser prejudicado.

Podemos consertar esse problema assim:

O segundo código muda pouca coisa, mas muda tudo: nele escolhemos as nossas medidas com a intenção de manter o tamanho da fonte adaptável para os diferentes padrões de fonte que nossos usuários podem ter.

E usamos a mesma racionalidade para o h1 e para o p, sendo coerentes com a nossa escolha inicial.

Isso não significa ser obrigado a usar a mesma unidade sempre, mas, sim, usar sempre a mesma linha de raciocínio.

Talvez a gente possa resumir isso em dois princípios:

• não use unidades diferentes para o mesmo objetivo;
• não use técnicas diferentes para fazer a mesma coisa;

d) Não use números mágicos

Quem nunca foi posicionar um elemento na tela e usou aquele número super preciso, que funciona perfeitamente, mas... de onde ele veio mesmo?

“Tentativa e erro, Caio. Deixa eu ser feliz!”.

Claro, claro. Mas eu estou aqui para te poupar de dores muito maiores, jovem gafanhoto.

Para exemplificar isso, me inspirei na Natália e fiz o começo de um desenho com CSS.

Na minha tela, essa posição para os olhos está funcionando perfeitamente. 58px! O que poderia dar errado?

Err... será que em outras telas funciona também?

Convido você a brincar de arrastar o tamanho da tela para ver que só em uma largura de tela específica que os olhos ficam no lugar desejado.

Lembre-se, temos sempre que pensar no filme, não na foto.

Conclusão

Esses são alguns dos princípios e técnicas que sigo ao criar projetos Front-end.

Planejando, tendo organização, coerência e tendo domínio do código que produzimos conseguimos criar projetos mais robustos.

Espero que você tenha gostado das dicas. Me conta aqui nos comentários algo que você faz e que eu não comentei. Me conta também sobre qual das dicas você nunca tinha parado para pensar.

Aproveito para agradecer à leitura atenta e às contribuições da Ângela e da Moni, que além de terem dado pitacos valiosos no texto, são inspirações para mim.