[Front-end] Duplicar não faz mal

Se tem uma coisa hoje que define o front-end moderno, é a componentização. Acabar com a duplicidade do código, criar páginas com recursos incríveis apenas encaixando componentes já prontos e claro ganhar velocidade na alteração do layout. Tem outros pontos positivos, mas já deu pra pegar a ideia. Mas até nesses três pontos citados, não são só flores.

Um princípio que resume tudo na vida, SRP. Quando criamos componentes precisamos ficar muito atentos ao seu nível de abstração, pois aqueles pontos positivos podem virar negativos rapidinho. Faz de conta que vamos criar uma página web para um ecommerce que vem crescendo rapidamente, você escolhe suas tecnologias e começa a seguir o design. O designer criou vários componentes bonitinhos e construiu todos os elementos, páginas e etc, ótimo.

Você, um cara sagaz, viu que de fato os itens foram replicados, logo você cria um componente para cada um e sai montando as páginas. Maravilhoso, job realizado, todos felizes, trabalho excelente, boa! Com o passar do tempo, a galera começa a pegar uns insights de melhoria do site. Eles viram aquela teoria das cores e decidiram mudar a cor do botão para adicionar um produto no carrinho para azul (porque transmite confiança) e a cor para fechar a compra do carrinho para vermelho (para excitar a fechar a compra). Simples, vamos fazer um bind da cor para que a página que renderiza aquele componente passe qual cor irá utilizar. Excelente, ótima sacada, o site ta ótimo.

Passando mais um tempo, percebe-se que ainda tem muitos carrinhos de compra sendo abandonados no site, então decidem aumentar o botão do carrinho e colocar uma tipografia diferente no botão de adicionar. Você vai lá e passa mais duas propriedades para seu botão, fonte e tamanho para deixar ele mais dinâmico. Mas pera aí, a gente até hoje tá deixando o botão habilitado quando o carrinho está vazio, vamos passar se ele precisa estar desabilitado ou não também. Querem colocar um efeito de hover diferente para algumas páginas também, mais uma propriedade, então começa formato, ícone, alinhamentos, margens e assim vai somando mais e mais propriedades para passar para o botão.

O site está indo muito bem, mas percebe-se que tem muitas compras sendo realizadas por usuários sem cadastro. Então, para motivar pessoas a se cadastrarem, no momento que apertarem o botão do carrinho, vamos apresentar um modal com cupom de desconto para quem se cadastrar. Mas agora, seu botão já recebe um bind de clicks e outras funções para outros comportamentos, fora que seu código está ficando um pouquinho grande demais, pois toda hora que você vai criar um simples botão, tem que passar 5-10 propriedades para ele. No caso do botão podemos deixar várias coisas padrão e sempre aumentar o handler do componente pai, mas a moral é que, às vezes, é melhor duplicar do que abstrair.

Quando temos componentes com muitas propriedades para passar, nosso código começa a feder um pouquinho… E quando esse componente precisa saber onde está para reagir de alguma forma diferente, é a receita do caos. Nesse exemplo de página de produto (listagem e detalhes) e carrinho de compras, podemos imaginar dois módulos completamente distintos do site, pois cada um tem objetivos e funcionalidades bem distintas. Ainda mais se lembrarmos que tem parte de cadastro, perfil e pagamentos. Um botão genérico pode existir, mas não seria interessante cada módulo ter seu exclusivo também?

Além de ter módulos distintos e componentes menores, nossas alterações ficam mais controladas, pois às vezes pode ser meio frustrante para os Stakeholders quando eles queriam alterar o design de tal componente em algum lugar específico e percebe que todos com componentes semelhantes do site mudaram também. Vejo muitos times esquecerem deste detalhe completamente, mudanças de layout vem para um módulo ou página específica e a galera não faz ideia que aquilo é um componente abstraído que irá impactar em outros lugares.

Eu sei que repetição de código não é nada legal, mas SRP sempre fala mais alto pois muita abstração aos poucos vai acabando com a flexibilidade do código. Sempre busque modularizar as coisas, pois às vezes temos até times diferentes para áreas específicas, componentes simples e de fácil utilização são bem melhores que componentes preparados para tudo. Por hoje é só, jogue safe. Abraços!