11-06-2024
Eis os “erros” mais comuns em Projetos Angular
Por Diogo Salaberri, Technical Project Manager
Vamos começar pelo início. Este não é um artigo para quem está a começar agora a sua jornada na Framework Angular, mas sim para quem já deu os seus primeiros passos com esta tecnologia e se deparou com algum problema, ou, até, dúvida de como conduzir algum desafio.
Obviamente, não posso deixar de trazer algumas palavras sobre o Angular na introdução deste pequeno blog post. O Angular é uma plataforma de desenvolvimento WEB, open-source e baseado em TypeScript – mas não se limita a isso. Tendo fornecido esta descrição complexa e completa (contém ironia), vamos avançar para o propósito deste artigo: falar rapidamente sobre erros ou más práticas que vemos com muita frequência nos projetos feitos com esta Framework.
Disclaimer
As citações descritas abaixo não estão em ordem de prioridade ou até mesmo de importância. Olhemos para elas como sugestões baseadas na experiência que tenho vindo a absorver.
Naming Convention, Sintax
É importante referir que o Angular já traz consigo uma série de padrões e boas práticas, desde convenções de nomes, sugestões de sintaxe, estrutura de projetos, entre outras. Principalmente se criarmos as estruturas Angular (Componentes, Serviços, Pipes, etc) pelo CLI. O que não devemos é, por sua vez, tentar “recriar a roda” e colocarmos os nossos padrões, ou, pior, misturar diversos padrões. Isto vai acabar por causar uma confusão muito grande no sistema, principalmente em casos onde temos uma equipa de desenvolvimento grande. Os padrões são ouro nas mãos de quem os valoriza!
Como mencionei acima, o Angular fornece e traz já consigo esta série de padronizações – deixo aqui uma referência da própria documentação da Framework para auxiliar e exemplificar o que foi descrito neste ponto.
Lazy Loading
O Lazy Loading é uma capacidade do Angular onde podemos procurar as estruturas (HTML, CSS, JS) por demanda. Por exemplo, se acedermos a uma certa Page/Module, só vamos precisar de procurar as estruturas necessárias para aquela renderização. O uso do Lazy Loading é, inclusive, encorajado para Projetos que tenham uma grande série de módulos, rotas, páginas, ou simplesmente projetos que sejam grandes, pois esta escolha fará com que o utilizador vá procurando as estruturas conforme estas sejam necessárias e não precise de procurar todo o conteúdo de uma só vez. Portanto, se o seu projeto começou a ganhar uma certa dimensão, faça uso do Lazy Loading. Abaixo, deixo uma referência da Framework onde este tópico é descrito com bastante detalhe.
State Management
A gestão do estado da aplicação é crucial em aplicações de grande porte. Lá, encontramos um local centralizado e confiável onde podemos partilhar dados que sejam de escopo global para a nossa app. Em relação a este ponto, não se esqueça de não fugir dos padrões – ou vai encontrar problemas de certeza! Não oiça aquele seu amigo que sabe uma forma de resolver, ou não sobrecarregue os Services para guardar aquela informação que “só vai ser usada ali”. Use, sim, as soluções que atacam esse problema diretamente e que, comprovadamente, o resolvem, como o NgRX, por exemplo.
Mais uma vez, deixo uma referência para que seja possível aprofundar o seu conhecimento sobre este tema.
Form Management
Os formulários são a forma mais comum de obtermos dados dos utilizadores, mas devemos ter certos cuidados com a gestão destas informações nas nossas aplicações. O Angular, à data de hoje, fornece duas abordagens para esta questão – “Reactive forms” e “Template-driven forms” – as duas bastante eficazes dependendo do seu caso e uso.
Importante: é completamente não aconselhável que faça isto manualmente, pois vai certamente colher maus frutos! Assim como falhar em validações de obrigatoriedade, formato e tipos de dados vão-lhe causar dores de cabeça. Para não falar somente do mais básico, é importante lembrar que a sincronização entre Model e View precisa de ser mantida. Se este passo for perdido, tudo é perdido!
Deixo aqui mais uma referência para mais detalhes.
Component Life Cycle
O Angular é uma framework baseada em componentes e estes, por sua vez, possuem um ciclo de vida bastante detalhado. O que o Angular faz é prover “Hooks” para as fases deste ciclo de vida – faça bom uso destes “Hooks”.
Entre os erros mais comuns neste tópico, é preciso lembrar a boa prática de sempre: cancelarmos os Observables no Hook ngOnDestroy, evitando assim vazamentos de memória e problemas de performance. Assim como a deteção de mudanças que, por vezes, não é percebida pelo Angular, o Hook ngDoCheck ajuda nesta situação, auxiliando a que escapemos de loops de mudanças infinitos. Neste tópico, ainda é possível citar diversas más práticas ou erros a serem (ou não) cometidos. Para que possa obter mais informações, deixo a referência abaixo, como de costume.
Estes são erros bastante comuns no desenvolvimento com Angular, e são exemplos muito contextuais e da vivência de cada um de nós. Certamente cada um de vocês consegue-se lembrar de algum outro caso do dia a dia.
Por isso, se estiverem confortáveis, desafio-vos a partilhem nos comentários as vossas experiências, para que todos nós fiquemos a saber o que “não” fazer.
