Angular Leading Practices

As my preferred single-page application framework, I’ve found a few things handy when working on an Angular application, which can be applied to both new Angular applications, along with currently existing applications.

Use Angular CLI

The first, and easiest one to follow, is to use Angular CLI as much as possible, mostly in the matter of creating different components, guards, services, and other entities for the application. This comes with the advantage of building out all of the appropriate files based on the project setup.

As an example, using ng generate component will create the following:

• Component file (.ts file)
• CSS module (depending on whether you’re using CSS, SASS, or LESS)
• Template file (.html)
• Test (.spec.ts)

All of this will be configured based on your projects settings, and this allows for a consistent file structure across the application.

Follow the Angular coding style guide

Another easy leading practice to follow is to adhere to the Angular coding style guide. This guide is maintained by the Angular team and provides a list of leading practices mostly related to file structure, naming, and information on the related entities that Angular provides.

Many of these also come with explanations on what makes them a leading practice, explaining why to follow a certain practice over another.

Use trackBy when using ngFor

ngFor is a pretty common function you’ll use in an Angular application - essentially any time you iterate over an array, you’ll use it to display each item in an array. If this array can change (adding and removal of objects as an example), Angular will re-render the entire collection, making for worse performance.

The solution is to use trackBy, which uniquely identifies the item in the array and allows for only re-rendering the changed item. You can see this in action with the example in this article.

Separate the application by using modules for lazy loading capabilities

By default, everything inside an Angular project sits inside a single module, meaning when the application grows in size, Angular will load the entire application before becoming functional. A solution to the increasing app size and subsequent performance issues at load time is to:

1. Break down the application into modules (which also makes for a more manageable codebase)
2. Set those modules to lazy-load when they’re required.

Breaking down sections into modules makes for a more manageable codebase - for instance, you might make a module based on each major area of your application (like an admin module, user module, etc.). This way, work is separated out into each module, and concerns in the application can be separated easily.

In addition, separated modules can be lazy-loaded, improving start-up performance in your application. This means the module as a whole won’t be loaded in the application until it’s requested, which works well in cases where parts of the application might not always be required for a user.

Keep templates as simple as possible

When setting up a template, it’s a good idea to remove as much computational logic as possible, putting everything in the component controller. Having all of the computational logic inside the controller makes for a better separation of concerns (the template should only be responsible for the markup structure, and and the compoment should handle all data manipulation). In addition, testing becomes easier when computational logic is completely decoupled from the template, as all testing can occur inside the component controller.

This article does a pretty good of going into the details of how to implement, specifically looking at Strategy 2.

Consider using Angular Universal for Server-Side Rendering

When looking to improve overall performance (especially on start-up), an approach to consider is to utilize server-side rendering with Angular Universal. Using server-side rendering provides a few benefits:

1. Allows for better SEO by faciliating web crawlers.
2. Provides better performance on mobile devices and slow connections.
3. Sets a quick first-contentful paint, making for a quickly performant app.

Using Angular Universal requires a server that can provide static HTML to the browser - most technologies are viable, but Node.js makes for an easy transition as the Angular SSR guide is written using Node.js.

Create small reusable components with as little internal state as possible

This leading practice goes across most SPAs, but keeping components as simple and reusable as possible makes for a much easier codebase to manage over time. Many times, this results in a component library where you are able to use reusable UI components across your application (or even across multiple applications, if this component library is moved into an Angular library).

This will reduce a large amount of code duplication in the application, and make the codebase more consistent. In addition, you can use a tool such as Storybook to make both development of these components easier to do, and demo of the components easier to do.

Wrapping up

Hopefully, these steps provide a means of leading your Angular application in the right direction. Whether you’re starting on a brand new Angular application and working through the base architecture, or you’re looking to refactor your existing application, this list should serve as a starting point for adhering to leading practices.