Three Angular mistakes to avoid
Throughout my career as a full stack engineer, I’ve worked on numerous commercial Angular projects and helped onboard dozens of developers. As a result, I noticed a few bad habits that develop organically, particularly among beginners.
In this article, I will discuss three of the most important pitfalls to avoid. They are: using function calls in NgIf directives, improper use of the RXJS library, and failing to leverage Angular’s fundamentals.
NgIf is a structural directive in Angular that can be used to show or hide dom elements based on some boolean value. The typical mistake to make when using this directive is to use a function call as the boolean expression, especially if the function demands some processing power.
Without going into too much detail about Angular’s inner workings, the problem with this technique is that the function will be called every time change detection runs, which can occur several times in a short period, and this will have a significant impact on
This article delves deeper into the subject, and I recommend it as additional reading!
To avoid this issue, the recommended approach performing expensive calculations when the underlying data changes, using the appropriate lifecycle hook (OnInit, OnChanges…etc) and storing the results in local variables.
“RxJS a library for composing asynchronous and event-based programs by using observable sequences,” according to their website. Every Angular project I’ve worked on has used RxJS in some way, and it’s safe to say that it should be included in every modern enterprise Angular application.
When utilized correctly, RxJS is a great tool for developing sophisticated reactive apps. The only drawback is the learning curve. It’s typically thought to be tough to learn, especially for newcomers inexperienced with functional programming.
In my experience, the most common misuse of the RxJS library is to subscribe to obsevables early and store values in local variables. This not only makes the code more difficult to comprehend, but it also results in a number of asyncronous issues that lead to obscure bugs in production.
The simplest approach to prevent this is to just use the library’s operators to manipulate the data without needing to unwrap it. I found a tool that makes it easy to decide on which operator to use based on the situation. Conveniently, It also links to the official documentation on the operator.
Additionally, Angular offers a comprehensive routing system that manages routing both within and between modules. Unfortunately, some solutions use NgIfs and Boolean flags to show and hide components, instead of creating new routes. The official documentation offers a fantastic place to start to learn all of this.
Another bad practice I have seen is not implementing Internationalization early in the project development cycle. Nowadays, it is practically required, for any enterprise application to support several languages; nonetheless, some projects still use hard coded English content in the templates.
The problem with delaying Internationalization is that it becomes substantially more time consuming to implement as the app expands. The official Angular documentation includes an overview of i18n.
Last but not least, in a previous article, I wrote about three important Angular concepts that helped me ace interviews and all three are part of the fundamentals of Angular.
Early in my career, I was fotunate to be onboarded onto an excellent Angular project that followed all the best practices. Since then, I’ve been able to easily recognize and avoid bad practices that other developers might have adopted. Three examples of these bad practices are the mis-use of the RXJS library, putting function calls in NgIfs and not leveraging the full power of the Angular framework.
Originally published at https://blog.mbcubeconsulting.ca on August 15, 2022.