Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
6 minutos de leitura
Autor(a)
Vivo no 220v, sempre atrás de um filme/rolê novo e codando desafios aleatórios em JavaScript. Adoro fazer sites e falar/dar aulas sobre isso no @nubank, meu canal no YouTube DevSoutinho e na @alura
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Em 2018 eu comecei a trabalhar com Styled Components. No começo eu tive muito preconceito, sempre ficava reclamando, dizendo que não entendia bem como usar e hoje em dia eu praticamente não me imagino fazendo um sem usar essa belezura.
A ideia desse post é compartilhar um pouco da minha experiência e tentar ti convencer a testar essa lib que pode ti ajudar a resolver vários probleminhas comuns que temos.
Para quem já trabalha a um tempo com Front End, é bem comum já estar acostumado a pensar em trabalhar com o CSS focando em reuso em cima de algum padrão, seja ele BEM, SMACSS…
O que para concluir as tarefas do dia a dia nos leva a escrever um código que segue essa linha:
E isso faz todo sentido funciona super bem e muitos projetos são estruturados assim, esse estilo de organização ganhou muita força quando logo que o SASS e sua trupe de pré processadores foram sendo lançados.
Porém no mundo do desenvolvimento nada para e as coisas seguem evoluindo e nesse ritmo de lançamentos essa estratégia foi portada para os Single File Components do Vue.js.
O mais legal dessa abordagem, é que destruimos tudo o que aprendemos nas bases do Front End que é deixar cada coisa em seu canto e juntamos tudo em uma coisa só. Porém muitas vezes acabamos não refletindo o por que disso ser algo tão difundido.
O estalo pra mim veio quando eu fiz um componente de acordeon, e vi que era muito fácil de ver toda a lógica do componente, seu estilo e qual era o markup (html) que estava servindo de base para o componente.
Se formos parar para analisar, basicamente todo componente que criamos em uma página vai possuir estruturas em comum: Um ou mais "wrappers", Os elementos filhos que compoem o componente em questão e caso seja algum componente com lógica e state precisaremos ter uma estrutura para usar os hooks ou mesmo a estrutura de classe do React.
Se formos parar para olhar o exemplo acima onde eu tenho um contador e sua estrutura, podemos ver que praticamente todos os componentes aqui são visuais, menos o que controla a lógica, e se fossemos criá-los com styled components nosso código ficaria assim:
O que é visual tem a sua criação abstraida e simplificada para nós e o bacana é que a API do styled components da suporte para todas as tags já conhecidas do HTML.
Nesse momento você pode ter curtido o código anterior e entendido mais ou menos como pensar em styled components, mas para quem escreve CSS o reuso ali pode ter ficado meio nublado de como pode ser feito, para isso vamos pensar no caso onde já temos um componente criado como um botão.
Caso tenhamos o interesse de aproveitar todos os seus estilos e apenas mudar o background, precisamos somente fazer isso aqui:
Uma dica super importante aqui na parte de reuso é que para o desenvolvimento ser bacana é legal fazer um mapeamento dos layouts do seu projeto quando for trabalhar, assim você evita ficar fazendo coisas muito repetidas e trabalha somente extendendo quando necessário em cima de uma base sólida.
Sempre que quisermos fazer algum estilo ser condicional, podemos passar propriedades para o componente como no exemplo abaixo e o estilo será adicionado somente quando o resultado esperado acontecer:
<AccordionContentArea accordionState={accordionState}>
<p>lorem ipsum sit dorme amet...</p>
</AccordionContentArea>
const AccordionContentArea = styled.article`
border: 1px solid rgba(0, 0, 0, 0.125);
padding: 0.75rem 1.25rem;
${({ accordionState }) => accordionState && `display: none;`}
`;
Ao meu ver uma das principais vantagens que temos aqui é com toda certeza a praticidade de poder ter um arquivo JavaScript com objetos definindo cores, valores padrões, breakpoints e etc.
A flexibilidade do uso de uma linguagem de programação que de fato vai rodar no browser acaba trazendo uma flexibilidade maior que um pré-processador pode acabar não oferecendo, e ainda tudo fica mais organizado do que se trabalharmos com as custom properties nativas do CSS que ainda são um pouco complicadas de manter principalmente no ponto da experiência de desenvolvimento onde fica complicado debugar valores e outras coisas comuns que fazemos com variáveis em linguagens de programação de verdade.
Outro ponto fantástico dos Styled Components é que como a parte visual é resultante de um componente, sempre que precisarmos deletar um código vai ser fácil saber onde estão todas as suas referências removendo tudo por completo, o que com CSS fica mais difícil pois é complicado termos um mapeamento do que está sendo trabalhando em cima de um seletor global que fazemos, é possível fazer usando algo como o BEM mas exige um esforço maior do time como um todo.
Mesmo que hoje ter CSS escopado não seja uma novidade, esse é um outro ponto super bacana ter o que o CSS Modules faz de forma nativa com a lib em cada componente alivia bastante a carga de lidar com estilos globais.
Um último ponto que é bem legal é que, o styled components tenta adivinhar o que seria o conteúdo above the fold do seu site e extrai esse CSS para o head, fazendo assim um carregamento mais rápido da parte crítica de renderização trazendo resultados bem legais em performance.
O acoplamento com a tecnologia é algo que você tem que estar ciente, se o seu site todo for feito com styled components, ele com certeza pode trazer uma carga cognitiva inicial para quem for trabalhar no time e não conhecer, principalmente pelo fato de ter uma abordagem radicalmente diferente das mais comuns que citamos anteriormente como trabalhar com algum pré-processador ou os single file components do Vue.
Um outro ponto que é importante falar aqui é que pode parecer que estamos repetindo muito mais do que o necessário conforme vamos desenvolvendo o projeto, por isso ressalto a importância de tentar definir bem os rumos da interface previamente para ter pelo menos uma noção geral de componentes principais como titulos, botões, menus entre outros...
Se você curtiu, não deixe de seguir minhas redes sociais procurando por @omariosouto e dar uma olhadinha no meu site que sempre ta saindo algo novo por lá https://mariosouto.com.br.
Até a próxima :)
Avalie este artigo
