Being an Angular developer we might witness so many best practices & bad approaches while developing an application. Obviously, when we explore the best practices, of course, we will note it down in our favorite list but most of the time we’re not certain about the mistakes & bad approaches being followed by us. Sometimes, we really need other Angular experts to address our mistakes in order to help us become a better coder.

Today, Our Angular experts like to address the 10 most common mistakes that angular developers will commit which are really needed to be taken care of.

1) Forgetting Unsubscription

Whenever we are using any subscriptions for observables or any events in our angular application, more often we forget to unsubscribe those events. In case, If we are not unsubscribing those events then it might lead to memory leaks across the entire system. Thus, we need to stop this immediately or should fix it in the initial stage itself. Let’s see how you can solve it.

You can solve it in two ways as mentioned below,

Start the onDestroy LifeCycle hooks when subscriptions in component Initiate LifeCycle hook by yourself when it is in service on which you have subscriptions

For example:-

// code start import { Component, OnInit, OnDestroy } from '@angular/core'; import { Observable } from 'rxjs/Observable'; @Component({ ... }) export class AppComponent implements OnInit, OnDestroy { destroy$: Subject<boolean> = new Subject<boolean>(); ngOnInit() { this.postSerive.getAllPosts() .takeUntil(this.destroy$) .subscribe(({data}) => { console.log(data); }); } ngOnDestroy() { this.destroy$.next(true); // Now let's also unsubscribe from the subject itself: this.destroy$.unsubscribe(); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 // code start import { Component , OnInit , OnDestroy } from '@angular/core' ; import { Observable } from 'rxjs/Observable' ; @ Component ( { . . . } ) export class AppComponent implements OnInit , OnDestroy { destroy $ : Subject < boolean > = new Subject < boolean > ( ) ; ngOnInit ( ) { this . postSerive . getAllPosts ( ) . takeUntil ( this . destroy $ ) . subscribe ( ( { data } ) = > { console . log ( data ) ; } ) ; } ngOnDestroy ( ) { this . destroy $ . next ( true ) ; // Now let's also unsubscribe from the subject itself: this . destroy $ . unsubscribe ( ) ; } }

2) Using Client-side Pagination

Moreover, it’s a process of data rendering which maintains to represent the bulk data in an application. When you use Client side pagination, Initially, you have to load the entire data. By the time, if you have fewer records then it will be easy to load. In future, when you have more number of records then it will be really hard at that time when the initial loading begins.

So what you can do? Is there any alternative way to solve it?

Yes, we have!

Server Side pagination

Using server-side pagination we can predominantly solve this issue. When you do server-side pagination, it will peculiarly hit the specific page number and will load the particular page records accordingly.

3) Handling DOM Changes Directly

Making changes in DOM directly is another bad practice we must avoid. When you want to add images or need to change the titles from page to page, at that time we all might have practiced doing the changes directly in DOM. But making changes to the DOM directly is not recommended in angular because the DOM is a browser specific API which will tightly couple your application code with the browser. This coupling will not allow us to target any other rendering environment.

Alongside, Angular provides built-in methods which abstract the DOM and let us make the changes to the DOM without the coupling such as ViewsChild or Renderer classes.

4) Involving Jquery

JQuery is a standard library used for the web and mobile applications. Whenever we want to do any DOM manipulations, immediately we might think of JQuery. But JQuery’s is not the best way to solve a problem in angular, much as Angular itself has plenty of its own features which you can effectively make use in your application instead of using third-party libraries for DOM manipulations.

5) Inappropriate Organization of Code

It is a widespread mistake did by everyone. Adding a bunch of the code in a single function will totally confuse us when ought to do any modifications. Also, it will be difficult for other programmers to understand. To prevent this, we can organize the code into small chunks based on the logic then we can collectively put together for easier code management.

6) Declaring Component Multiple Times

Component is the main part we need to consider in angular application. Every component needs to be declared in corresponding NgModule of declarations array. There is no way to declare one component in more than one NgModule. If you declare then it might throw you an error. So, If you really want to use one component in multiple modules then the best way to do is to move that component to the shared module including the declarations array and exports array as well

After that, you can import the SharedModule wherever you want,

Example for declaring and exporting PostComponent in SharedModule

Example:-

NgModule({ declarations: [PostComponent], exports: [PostComponent] } export class SharedModule { ... } // importing SharedModule in ArticlesModule NgModule({ imports: [SharedModule] } export class ArticlesModule { ... } // importing SharedModule in NewsModule @NgModule({ imports: [SharedModule] } export class NewsModule { ... } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 NgModule ( { declarations : [ PostComponent ] , exports : [ PostComponent ] } export class SharedModule { . . . } // importing SharedModule in ArticlesModule NgModule ( { imports : [ SharedModule ] } export class ArticlesModule { . . . } // importing SharedModule in NewsModule @ NgModule ( { imports : [ SharedModule ] } export class NewsModule { . . . }

7) Component.Providers Vs NgModule.providers

The Hierarchical dependency injection, services can instantiate more than one times in the angular application

For example, have a look at the service declared in component providers

@Component({ selector: 'hero', template: '...', providers: [HeroesService] }) export class HeroComponent { constructor(private heroesService: HeroesService) {} } @NgModule({ declarations: [HeroComponent] } export class HeroesModule { ... } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 @ Component ( { selector : 'hero' , template : '...' , providers : [ HeroesService ] } ) export class HeroComponent { constructor ( private heroesService : HeroesService ) { } } @ NgModule ( { declarations : [ HeroComponent ] } export class HeroesModule { . . . }

In the above Example, HeroesService declared in HeroComponent providers array and injected it in the constructor. The problem here is, HeroComponent instance will create a new instance of HeroesService every time. As a result, HeroesService will fetch the data by HTTP request which multiples because of Hierarchical Dependency Injection.

Declaring service in @NgModule.Providers array is the right solution for this problem,

@Component({ selector: 'hero', template: '...' }) export class HeroComponent { constructor(private heroesService: HeroesService) {} } @NgModule({ declarations: [HeroComponent], providers: [HeroesService] } export class HeroesModule { ... } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 @ Component ( { selector : 'hero' , template : '...' } ) export class HeroComponent { constructor ( private heroesService : HeroesService ) { } } @ NgModule ( { declarations : [ HeroComponent ] , providers : [ HeroesService ] } export class HeroesModule { . . . }

Once you do this, the provider will instantiate service only one time for all HeroComponents. Because by then this service will act as a Singleton after declaring service in NgModule providers. Paralelly, other modules also can able to use this service so no need to declare in exports hence it will be done automatically.

Best To Read: Top 10 Angular Best Practices You Must Know

8) Failing To Do Adequate Testing

After developing the application many developers might forget to test the application in cross browsers. We can able to identify the strange bugs only when we test it in different environments. Therefore, test your application with multiple environments and in case if you feel it’s difficult to maintain the OS, then you can try using online testing tools like LambdaTest tool or BrowserStack test tools and many testing tools that are available. These tools can provide 2000+ browsers and various operating system including mobile device OS and it also helps us to take screen records.

9) Inconsistent Naming

Another common mistake is inconsistency in naming things, not having a common name for components, services, functions, variables which might get us confused to understand the original functional flow. You can overcome this unwanted conflicts by using a proper name for identifying components, services, functions and etc and this will help us to quickly address the changes without any conflicts.

10) Irrelevant Commit Messages

Sometimes a single irrelevant commit message can change the entire the code as it confuses the code reviewers. Also, it remains a pit hole for developers to find where they exactly need to revert the changes. So, avoid giving irrelevant commit messages & make sure to check before you proceed, also don’t forget to follow good standards from git.

These are the quick checklist we curated to help you from committing unwanted mistakes that affects the app performance. We had love to make this list better with your suggestions. Post us your best practices & suggestions to make the list better.

If you are looking for a skilled Angular developer. Agira has the experts in the industry to help you out in your Angular project. Hire an Angular developer for your project right now!

Don’t forget to subscribe to our weekly newsletters for more such goodies from our blog.