Best Practices for Writing Angular 6 Apps

“A desaturated shot of a tall skyscraper” by Changyu Hu on Unsplash

Considering that I have been using Angular for the past year or so, I find it one of the best front-end frameworks out on the web today. Google’s Angular team did their best to rewrite the framework and today we have a great tool for developing awesome single page applications. This article’s focus will be the latest version of Angular, which was released recently. I will assume that you have a basic to intermediate knowledge of Angular at least before you delve deep into this article.

Without further ado, let’s list some of the best practices for writing clean and usable Angular apps.

1. Use of Angular CLI

Angular comes equipped with a command line interface called Angular CLI, which helps you scaffold your code in minutes.

Angular CLI can be installed easily via terminal by typing in the following command:

npm install -g @angular/cli

Both the CLI and generated project have dependencies that require Node 8.9 or higher, together with NPM 5.5.1 or higher, so make sure to install those.

To generate and start a new project locally, use:

ng new PROJECT-NAME
cd PROJECT-NAME
ng serve -o

The tool can also be used for generation of modules, services, components, directives and pipes. I won’t detail those commands here. However, feel free to visit Angular CLI’s official website for more info.

2. Develop Angular apps in modular fashion using core, shared and feature modules

When you start developing in Angular, you may be tempted to disregard creation of modules for the sake of using components solely. That approach might be fine for smaller apps, but as your app starts to grow, development will become cumbersome. That’s when separation of concerns steps in, which is fueled by a modular Angular app.

Splitting your app into core, shared and multiple feature modules will make your life much easier. Each module can have its own components, services, directives and pipes.

Core module should be created of components (i.e. header, main navigation, footer) that will be used across the entire app.

Shared module can have components, directives and pipes that will be shared across multiple modules and components, but not the entire app necessarily.

Last but not least are feature modules. Per Angular’s official documentation, feature module is:

an organizational best practice, as opposed to a concept of the core Angular API. A feature module delivers a cohesive set of functionality focused on a specific application need such as a user workflow, routing, or forms. While you can do everything within the root module, feature modules help you partition the app into focused areas. A feature module collaborates with the root module and with other modules through the services it provides and the components, directives, and pipes that it shares.

3. Lazy loading a feature module

Lazy loading a feature module is the best approach when it comes to accessing a module via Angular’s routing. That way we will be able to make our Angular app faster. In other words, a feature module won’t be loaded initially, but when you decide to initiate it. Therefore, making an initial load of the Angular app faster too! It’s a nifty feature.

Here is an example on how to initiate a lazy loaded feature module via app-routing.module.ts file.

const routes: Routes = [
  {
    path: 'dashboard',
    loadChildren: 'app/dashboard/dashboard.module#DashboardModule',
    component: CoreComponent
  }
];

4. Use of smart vs. dummy components

Most common use case of developing Angular’s components is a separation of smart and dummy components. Think of a dummy component as a component used for presentation purposes only, meaning that the component doesn’t know where the data came from. For that purpose, we can use one or more smart components that will inherit dummy’s component presentation logic.

Here is a useful read that will give you more insight on the subject, because the complexity of the matter requires a new post/article.

5. Proper use of dependency injection in Angular 6

Come Angular 6, there have been some changes for the better when it comes to providing services in Angular. The old way would be to state services explicitly inside providers inside of NgModule. Not anymore. If you have been using the latest version of Angular and Angular CLI, you will notice that the CLI generates the following piece of code whenever you generate a new service:

@Injectable({
  providedIn: 'root'
})

It is the new way of providing services in Angular. Also, please note that root can be replaced with any module where you wish to provide your service with. Your old code will still work, but consider replacing it with the new one as soon as possible.

6. Aliases for imports

Creating aliases for imports is a plus. We may use imports three folders deep sometimes, so the following import is not the ideal solution:

import { LoaderService } from '../../../loader/loader.service';

Add the following piece of code into tsconfig.json file to make your imports short and well organized across the app:

{
  "compileOnSave": false,
  "compilerOptions": {
    removed for brevity,
    "paths": {
      "@app/*": ["app/*"],
      "@env/*": ["environments/*"]
    }
  }
}

When you’re done, these imports

import { LoaderService } from '../../../loader/loader.service';
import { environment } from '../../environment’;

should be refactored into these:

import { LoaderService } from '@app/loader/loader.service';
import { environment } from '@env/environment’;

Short and sweet!

That’s it.

I hope that you find some of these tips useful and that they can serve as pointers at least. Also, please support this article with claps and feel free to add your thoughts in the comments section below. Thanks for reading!

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.