Contact Us
Here are the most common “mistakes” in Angular projects
Tempo de leitura: 3 minutos

Here are the most commonmistakes” in Angular projects

By Diogo Salaberri, Technical Project Manager

Let’s start at the beginning. This is not an article for those just beginning their journey with the Angular Framework, but rather for those who have already taken their first steps with this technology and encountered a problem, or even a question on handling a challenge. 

Naturally, I must include a few words about Angular in the introduction to this small blog post. Angular is an open-source web development platform based on TypeScript, but it doesn’t stop there. Having provided this complex and complete description (it contains irony), let’s move on to the purpose of this article: to briefly discuss errors or poor practices we often see in projects using this Framework. 


The points described below need to be in order of priority or even importance. Think of them as suggestions based on the experience I have been absorbing. 

Naming Convention, Syntax 

It’s important to mention that Angular already comes with various standards and best practices, from naming conventions and syntax suggestions to project structure. Especially if we create Angular structures (Components, Services, Pipes, etc.) through the CLI. What we should not do, however, is try to “reinvent the wheel” by imposing our standards or, worse, mixing various standards. This will end up causing a lot of confusion in the system, especially in cases where we have a large development team. Standards are gold in the hands of those who value them! 

As mentioned above, Angular already includes this series of standardizations—I leave a reference from the Framework’s documentation to assist and exemplify what has been described. 

Lazy Loading 

Lazy Loading is an Angular capability that allows us to fetch structures (HTML, CSS, JS) on demand. For example, if we access a specific Page/Module, we only need to search for the structures necessary for that rendering. Lazy Loading is even encouraged for projects with a large number of modules, routes, pages, or simply large projects, as this choice will allow the user to search for structures as needed and not have to search all the content at once. Therefore, if your project has started to gain a specific size, use Lazy Loading. Below, I leave a reference from the Framework where this topic is described in detail. 

State Management 

The management of the application’s state is crucial in large applications. There, we find a centralized and reliable place where we can share data that is of global scope for our app. Regarding this point, do not deviate from the standards—or you will undoubtedly encounter problems! Do not listen to that friend who knows how to solve it, or do not overload the Services to store that information that “will only be used there.” Use, indeed, the solutions that directly address this problem and that provenly solve it, like NgRX. 

Once again, I leave a reference so that you can deepen your knowledge on this topic. 

Form Management 

Forms are the most common way to obtain data from users, but we must manage this information carefully in our applications. To date, Angular provides two approaches to this issue—”Reactive forms” and “Template-driven forms”—both quite effective, depending on your case and use. 

Important: It is entirely inadvisable to do this manually, as it will undoubtedly reap poor results! Failing mandatory validations, format, and data types will cause you headaches. Not to mention the most basic, it’s important to remember that synchronization between Model and View needs to be maintained. If this step is recovered, everything is recovered! 

I leave here another reference for more details. 

Component Life Cycle 

Angular is a component-based framework, and these components have a very detailed life cycle. Angular provides “Hooks” for the phases of this life cycle—make good use of these “Hooks.” 

Among the most common errors on this topic, it’s necessary to remember the good practice of always cancelling Observables in the ngOnDestroy Hook, thus avoiding memory leaks and performance issues. Change detection, which sometimes is not perceived by Angular, is also helped by the ngDoCheck Hook, helping to escape from infinite change loops. In this topic, it’s still possible to mention various bad practices or errors that must be committed. For more information, I leave the reference below, as usual. 

These are common errors in Angular development and are contextual examples of our experiences. Indeed, each one of you can remember some other daily case. 

Therefore, if you feel comfortable, I challenge you to share your experiences in the comments so that we all learn what “not” to do.