Top Mistakes Developers Do While Coding with Angular
AngularJS is one of the most popular JavaScript frameworks accessible today. AngularJS major goal is to bridge the development process which makes it great for prototyping small applications, but its power allows scaling to full-featured client-side applications. The combination affluence of development, breadth of features, and performance has led to wide implementation, and wide implementation comes with many common drawbacks. This list captures common AngularJS mistakes, so explore this article and know the major mistakes done by developers while coding with Angular.
USING NGONCHANGES TO SPOT QUERY LIST CHANGES
In Angular 1, if the user wanted to be notified when a value changed, the user has to set a $scope.$watch and physically check for changes in each digest cycle. In Angular 2, the ngOnChanges links greatly and streamlines this process. Once the user defines a ngOnChanges method in his/her component class, it will be called whenever the component’s inputs change.
But, the ngOnChanges method executes only when the component’s inputs change -especially, those items the user have included in his/her inputs array or explicitly labeled with an @Input decorator. It will not be called when items are added or removed from @ViewChildren or @ContentChildren query lists.
If the user wants to be alerted for changes in a query list, then the user should not use ngOnChanges. In its place, the user should subscribe to the query list’s built-in observable, it “changes” property. As long as the user do so in the proper lifecycle link, the user will be alerted whenever an item is added or removed.
@Component({ selector: ‘my-list’ })
export class MyList implements AfterContentInit {
@ContentChildren(ListItem) items: QueryList;
ngAfterContentInit() {
this.items.changes.subscribe(() => {
// will be called every time an item is added/removed
});
}
}
CALLING DOM APIS DIRECTLY
There are very few circumstances where manipulating the DOM directly is necessary. Angular 2 provides a set of leading, high-level APIs such as queries that one can use instead. Leveraging these APIs confers distinct advantages:
- It is possible to unit test the application without touching the DOM, which removes difficulty from testing and helps the user tests run faster.
- It decouples the user’s code from the browser, allowing the user to run the application in any rendering context, such as web workers or outside of the browser completely.
When the user manipulates the DOM manually, the user will miss out the above advantages and ultimately end up writing less expressive code.
QUERY RESULTS IN THE CONSTRUCTOR
While playing around with queries, it is easy to fall into this ploy.
@Component({…})
export class MyComp {
@ViewChild(SomeDir) someDir: SomeDir;
constructor() {
console.log(this.someDir); // undefined
}
}
When the console logs are “undefined”, the developer might assume the query is not working or the developer itself constructed it imperfectly. It is important to remember that query results are not yet available when the constructor executes.
BINDING TO THE NATIVE “HIDDEN” PROPERTY
In Angular 1, if the user wants to adjust the visibility of an element, the user can use one of the Angular’s built-in directives, such as ng-show or ng-hide
Angular 1 example:
<div ng-show=”showGreeting”>
Hello, there!
</div>
In Angular 2, template syntax makes it available to bind to any native property of an element. This is very powerful and opens up a number of possibilities. One option to bind to the native hidden property, which is similar to ng-show, and sets the display to “none”.
Angular 2 [hidden] example:
<div [hidden]=”!showGreeting”>
Hello, there!
</div>
At first sight, binding to the hidden property seems like the closest cousin to Angular 1 ng-show. However, there is one “!important” difference.
ng-show & ng-hide together handles visibility by adjusting “ng-hide” CSS class on the element, which sets the show property to “none” when applied. Importantly, Angular controls this style and postscripts it with “!important” to assure that it always overrides any other display styles set on that element.
THE VERDICT
AngularJS is a great framework that continues to grow with the community. AngularJS is still a growing concept, but hopefully by following these pacts some of the major pitfalls of scaling an AngularJS can be averted.