18 posts tagged with "reactjs"

Muitas pessoas ainda associam o termo frontend apenas à aparência visual de um site ou aplicativo — cores, botões, layouts.

Aquela famosa frase "é só um botão". Mas não entende o que está por traz daquele simples botão que dispara várias ações na interface do usuário e, na maioria dos casos, em outros sistemas via api, por exemplo.

O desenvolvimento Front-end é frequentemente mal compreendido. Muitas pessoas ainda limitam sua definição à camada puramente visual — "é só colocar um botão ali" ou "só precisa mudar essa cor". Este equívoco subestima a complexidade e o impacto que decisões arquiteturais têm no desenvolvimento web moderno.

E com a vinda do Vibe Coding, essa visão pode ser acentuada. Front-end é só HTML e Backend é um bando de CRUD.

Quem trabalha com desenvolvimento sabe que não é assim que funciona. Um sistema simples feito em 1h e que escale? Boa sorte.

Este é um artigo que quero escrever há muito tempo mas só enrolo... Hoje acordei às 5h e, por alguma força oculta da natureza, sentei em frente o PC pra poder escreve algo misterioso que sai da minha cabeça.

Sem mais enrolação, o objetivo aqui é descrever algumas arquiteturas Front-end que é um tema complexo e estranhamente abordado.

Neste artigo vou abordar um exemplo de arquitetura e armadilhas por não seguir um padrão bem definido. O que trago é uma visão do desenvoveldor de software e coisas que ele deve se preocupar para mitigar problemas futuros, para ele e para a empresa.

Arquitetura de sofware é sobre o que é importante para o negócio.

Evolução de carreira é um tema muito importante — e, muitas vezes, pode ser desafiador traçar os caminhos certos ou escolher os temas ideais para estudar.

Pensando nisso, compartilho aqui alguns tópicos essenciais para quem deseja ingressar ou se aprofundar no desenvolvimento Front-end.

Design de aplicações é um tema extremamente importante para o desenvolvimento de software. Vejo muitas pessoas não tendo ideia de como criar uma boa arquitetura, podendo criar grandes complicações à medida que o sistema vai evoluindo, novas features, novas demandas, problemas, pressão por entrega e muitos outros fatores que contribuem para o aumento da complexidade da aplicação.

Sistemas inteiores podem ser refeitos pelo simples fato do time não ter criado uma boa arquitetura, ao menos um início ideal que possibilite evolução e adaptação do projeto. Isso pode ocorrer por diversos fatores, falta de conhecimento e pressão para realizar a entrega (muito comum), este último cria uma armadilha por achar que pular etapas do software visando somente velocidade e entrega não vai afetar a qualidade e escala.

Neste artigo vou abordar alguns problemas que podem ocorrer por não seguir um padrão bem definido. O meu objetivo é trazer a visão do desenvolvedor de software e coisas que ele deve se preocupar para mitigar problemas futuros, para ele e para a empresa.

Uma coisa bem simples, mas que pode virar um grande problema para projetos Web é a organização de ícones.

É extremamente comum o uso de bibliotecas como HugeIcons, Lucide, Material Icons, Font Awesome, React Icons e muitas outras e bem natural que o time/pessoa responsável pelo design crie os próprios icons, de acordo com a necessidade do projeto e da equipe.

Essa escala e mistura de ícones pode acarretar despadronização do projeto, muitas bibliotecas exportam ícones parecidos e com uma infinidade de características.

Uma forma que gosto de fazer para evitar este problema é padronizar os ícones em um único arquivo, exportando somente os possíveis no projeto.

Manter uma code base atualizada pode se tornar difícil à medida que o projeto cresce e novas funcionalidades e bibliotecas vão sendo adicionadas.

Durante todo o projeto, atualizações minor e patch são muito comuns nas bibliotecas e, na maioria dos casos, não causam transtornos e até mesmo são transparentes para o time de desenvolvimento.