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

Quando estamos aprendendo a programar a gente se acostuma a seguir tutoriais. O instrutor faz, a gente segue tin tin por tin tin, a coisa (quase sempre) funciona, o mundo é lindo e os passarinhos cantam.

Aí a gente vai fazer nosso primeiro projeto por conta própria (ou segundo, ou terceiro...) e bate aquela sensação... E agora? O que eu faço? Por onde começo?

Eu passei por essa situação bem mais de três vezes, cara leitora/caro leitor. Com o tempo, fui reunindo alguns hábitos e práticas que me ajudam a ter maior controle e eficiência nos projetos em que trabalho. Reuni neste artigo algumas dessas dicas/conselhos que vão aumentar sua produtividade, a qualidade do seu código, além de te ajudar a ter mais segurança na hora de começar novos projetos.

É bom logo tirar uma coisa do nosso caminho: não existe maneira certa de fazer esse tipo de coisa, apenas maneiras não-erradas. Essas práticas me ajudam, e pode ser que algumas dessas coisas não funcionem para você. Ficarei feliz em ler todos os feedbacks e experiências, o campo de comentários está aberto. Educados comentam.

1) Planejamento

A primeira coisa a se fazer para escrever um bom código é: não abra o seu editor de código favorito agora.

É isso mesmo que você leu. Deixa para abrir o VS Code daqui a pouco.

A gente começa planejando. E para isso vamos abrir o leiaute que vamos construir.

Com sorte, você recebeu um arquivo de referência criado por uma/um designer. Com mais sorte ainda, a/o designer teve tempo de ser meticulosa/o e todos os elementos do leiaute seguem uma lógica: os espaçamentos, respiros, tamanhos de fontes, tudo tem alguma coerência interna.

Mas no mundo real estamos todos trabalhando com prazos apertados, e algumas coisas podem passar batidas. É nosso trabalho interpretar aquele arquivo, entender qual era a intenção de quem criou, perguntar quando houver dúvidas e sugerir alterações.

Com o leiaute aberto, você vai prestar atenção nos seguintes pontos:

a) Existe um guia de estilo?

Aqui é a hora de construir o nosso guia de estilos no CSS. Vamos olhar para o leiaute e nos perguntar: Quais são as cores utilizadas? Quais são as fontes utilizadas (família, tamanho, peso)?

Eu costumo fazer isso criando propriedades personalizadas no CSS (CSS Custom Properties), que muitas vezes chamamos de variáveis CSS.

Nas Custom Properties eu defino todas as cores do projeto, font-family, font-weight e font-size. Assim, alguns tipos de mudanças podem ser feitas no guia de estilo do projeto, sem precisar acessar cada ocorrência daquela propriedade.

O resultado fica algo mais ou menos assim:

:root{
--color-main: #FF0000;
--color-secondary: #00FF00;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

Não reparem na escolha de fontes e cores. O que quero demonstrar aqui é que nosso guia de estilos vai estar definido nessas variáveis e pode ser acessado e modificado com facilidade, pois a fonte daquela informação está em apenas um lugar.

Um exemplo do que poderia acontecer: digamos que a empresa foi comprada por outra, que reformula a identidade visual, mudando as cores da marca. Em vez de correr atrás de todas as ocorrências de cores, podemos apenas alterar no nosso guia de estilos:

:root{
--color-main: #FFFF00;
--color-secondary: #00FFFF;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

Assim as mudanças serão replicadas onde quer que eu tenha colocado as Custom Properties "color-main" e "color-secondary".

b) Qual o alinhamento? Existe uma linha de grade?

O alinhamento é um dos principais responsáveis por orientar a leitura do usuário. Alinhamento é aquela linha invisível que passa pelas extremidades do conteúdo do site. A ponta esquerda do conteúdo do seu header é uma das linhas de grade do seu site. Um site com alinhamento coerente e intuitivo melhora muito a experiência do usuário. Por isso é importante que você tenha clareza no início do projeto quantas larguras diferentes de seção vai haver no site.

Aqui temos um exemplo de um site desalinhado. Criei as bordas laterais para que a gente possa ver como não existe padrão nenhum no alinhamento.

Olha só como fica bem melhor com um alinhamento feito com mais cuidado:

Quando estamos começando, fazemos o alinhamento caso a caso, seção a seção. O que acaba acontecendo: seguimos critérios diferentes a cada vez que fazemos. Uma hora definimos a width da seção com px, depois com %, mais na frente fazemos usando padding. Isso faz com que a gente não tenha clareza de qual é o tamanho que cada tipo de seção do site deve ter. E se isso não está claro na sua cabeça enquanto você está programando, isso não vai estar claro no seu código, nem vai estar claro na tela.

Para fazer esse trabalho a gente usa os containers. A gente ouve essa palavra, vê em códigos de cursos, mas muitas vezes não paramos para pensar qual a finalidade desse tal de container.

O papel de um container é... conter um determinado conteúdo.

Tá, tá, vou dar uma definição menos óbvia.

O container é responsável por definir a largura máxima dos elementos que estão dentro dele. Se temos dois conteúdos distintos com a mesma largura e alinhados ao centro, podemos ter (quase) certeza que esses conteúdos estão alinhados. Digo 'quase' porque podemos quebrar esse alinhamento colocando padding no container, por exemplo, estragando o alinhamento que o container estava tentando criar.

Há duas técnicas para a criação de um container. Uma usa width e a outra usa padding lateral. Elas tem suas vantagens e desvantagens e vou explorar isso mais a fundo em um artigo em breve.

“Tá, Caio, mas e se eu tiver várias larguras diferentes?”

Pode ser o caso de você conversar com o designer para entender melhor as linhas de grade do projeto. Pode ser que determinada seção possa aumentar um pouco, outra possa diminuir e vocês consigam uniformizar um pouco as linhas de grade.

Nos seus projetos pessoais, comece usando um tamanho só de container. Depois aumente para dois. Isso vai te dar uma clareza maior, e treinar seu olhar para identificar conteúdos desalinhados.

Naquele exemplo do caio-chella - projeto criado durante o Challenge Front-End da Alura que aconteceu em março de 2023) - eu estruturei da seguinte maneira:

:root{
--container-width: 86.5%;
}

.container{
   width: var(--container-width);
   margin-inline: auto;
}

Dessa forma eu estabeleci uma mesma largura para todos os meus containers, e na classe container eu aplico essa largura, além de alinhar ao centro com a propriedade margin-inline.

Se quiser conferir o projeto, dá um pulo no meu github: https://github.com/marcelluscaio/Codechella_AluraChallenge/tree/main

c) Há elementos gráficos repetidos?

O cérebro humano evoluiu para reconhecer padrões. E que sensação gostosa quando nós identificamos um! Essa sensação boa que a familiaridade traz está chumbada no nosso cérebro. Isso se reflete no design de sites.

Seria muito estranho que um botão na primeira seção do site fosse retangular e azul e outro no final fosse redondo e rosa, não é? Por isso, normalmente o design de um site costuma ter elementos semelhantes.

Esses elementos semelhantes terão a estilização semelhante no CSS. Agora é a melhor hora para identificar esses elementos e criar componentes e classes utilitárias. Para isso, a gente vai criar classes no CSS que reúnem todas as características comuns daquele componente.

A distinção que faço aqui entre componentes e classes utilitárias é meramente teórica, e tem a ver com o tipo de propriedade que as classes manipulam. Se está lidando apenas com elementos da tipografia, por exemplo, entendo que estamos diante de uma classe utilitária (como no exemplo de fontes que irei dar mais adiante). Se estamos lidando com mais de uma característica do elemento, entendo que estamos diante de um componente (como no caso do container ali em cima, e do botão que vou mostrar logo adiante).

Essa distinção é menos importante que a lógica por trás dela, não se apegue muito a isso.

Digamos que você viu que os botões do seu site todos tem fundo vermelho e cor do texto verde. O que você faz?

Demite seu designer!

Brincadeira! Ao percebermos esse padrão, podemos criar uma classe que vai reunir essas características:

:root{
--color-main: #ff0000;
--color-secondary: #00ff00;

}

.button{
background-color: var(--color-main);

color: var(--color-secondary)
}

Você pode observar ainda outras características em comum aos botões, como padding, border-radius e text-align, por exemplo.

Outro elemento de um site que costuma ter um alto grau de padronização é a tipografia.

Vale a pena dedicar um tempo para anotar todos os tamanhos de fonte, famílias, peso e altura da linha para compreender o padrão do site. Fazendo isso, podemos chegar ao seguinte resultado:

:root{
--ff-calistoga: 'Calistoga', cursive;
--ff-raleway: 'Raleway', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 24px;
--fs-3: 48px;

}

.title{
font-family: var(--ff-raleway);
font-weight: var(--fw-2);
font-size: var(--fs-3);
line-height: 1.2;
}

.title--small{
font-size: var(--fs-2)
}

.text{
font-family: var(--ff-calistoga);
font-weight: var(--fw-1);
font-size: var(--fs-1);
line-height: 1.5;
}

.text--bold{
font-weight: var(--fw-2);
}

E aí no seu HTML você pode fazer algo do tipo:

<h1 class="title">Título</h1>
<h2 class="title title--small">Título menor</h2>
<p class="text">Texto</p>
<p class="text text--bold">Texto em negrito</p>

d) Qual foi a largura de tela utilizada no leiaute?

Muitas vezes nós olhamos o leiaute e tentamos replicar ele na nossa tela: “O designer colocou 30px de padding lateral na página? Vou colocar o mesmo aqui na minha página e vai ficar igualzinho”.

Eis que você chega num ponto em que não consegue reproduzir fielmente o que vê no leiaute. “Mas eu coloquei exatamente as mesmas medidas que estavam lá! Viu, Caio, por isso que eu não gosto de front!”.

Eu entendo a sua revolta, mas eu posso te ajudar a nunca mais ter esse problema. A questão aqui é simples: o leiaute é apenas uma fotografia da nossa aplicação.

Essa foto é como um mapa que vamos seguir, e ali estão representados alguns momentos-chave da nossa aplicação – no geral a versão mobile e desktop (se você tem mais do que isso você é privilegiado SIM).

O desenvolvimento do site é um filme, a junção de todas essas fotografias/cenas.

Cada cena é uma largura de tela, e devemos pensar como toda a movimentação dos atores - nossos componentes/elementos em tela - está acontecendo. Algo pode sair muito bem na foto aos 1700px, mas quando chega aos 1300px alguma coisa pode quebrar, ficar fora de quadro.

Um grande salto na mentalidade de um bom desenvolvedor é parar de olhar a foto (“funciona na minha tela!”) e passar a se preocupar com o filme (“Como será que isso vai se comportar quando a tela for menor/maior que a minha? Qual é a experiência do usuário do produto que estou criando?”).

Então, quando olhamos para o leiaute é essencial pensar qual momento do nosso site aquele leiaute está retratando. Se olharmos para um leiaute construído em 1700px e começarmos a construir o nosso site na nossa tela de 1300px vamos criar distorções involuntariamente.

Lembre-se, o dev tools é o seu melhor amigo.

e) Mobile-first ou Desktop-first?

Outro ponto para considerar é: qual paradigma adotar no projeto, mobile-first ou desktop-first? Caso você não saiba do que estou falando, esses são dois paradigmas que definem como vamos começar o nosso projeto: “mobile-first” (celular primeiro) desenvolve primeiro a versão mobile e “desktop-first” (computador primeiro) começa pela versão desktop.

É bom você se acostumar com esses conceitos. =)

Mas afinal, por onde começar, pelo desenvolvimento para celulares ou para desktop?

Se alguma vozinha aí dentro da sua cabeça já está tipo a Hermione, afoita para responder, gritando “DEPENDE! DEPENDE!” você está no caminho para se tornar sênior! 500 pontos para a grifinória!

Na minha experiência, começar pelo desenvolvimento para celulares facilita muito o trabalho, mas não quero me aprofundar nesse tema aqui, senão a gente se perde do assunto principal. A escolha entre os dois paradigmas é livre, mas deve ser consciente. E ela é importante porque isso vai afetar como você declara as suas media queries.

Se você começa desenvolvendo para uma tela de 370px, por exemplo, quando for adaptar para telas maiores, digamos 1200px, vai usar min-width 1200px.

Se, por outro lado, começou desenvolvendo para 1653px, quando for fazer a versão tablet vai precisar declarar a media query com max-width 768px, por exemplo.

Manter suas media queries em ordem é muito importante para não surtar na hora de caçar bugs.

Conclusão

Seguindo todos esses passos do planejamento nossos projetos ficam muito melhor organizados, e a gente passa a ter muito mais controle sobre o que está acontecendo na tela.

Mas a gente mal começou a escrever código. Semana que vem eu trago mais dicas para tornar o seu projeto ainda mais robusto.

Me conta aqui nos comentários: qual dica você mais gostou, e de qual sentiu falta?