Refactoring Angular Applications

Chapter 4. Refactoring and Best Practices

Since refactoring is the process of making your code more readable, it makes sense to adopt uniform coding styles to reduce the cognitive load of reading and understanding code.

Code is confusing to read when each component looks like it was written by a different developer. Differences in spacing, semicolon use, opening brace alignment, etc., can make functionally identical code look different. Although it may seem surprising to consider this a refactoring, cleaning up code by applying consistent styles fits our definition of improving the ease of understanding the code without changing its behavior.

When a team is using the same coding practices, the “tells” of the original coder will fade away. Instead of the code looking like it came from multiple individual contributors, it will start to look like it was written by a unified team.

Having a style guide and coding standards also helps developers new to the project get up to speed faster. The style guide provides the answer as to what is expected for making contributions to the code base.

Use a Style Guide

A style guide provides rules for formatting and structuring common coding patterns. Instead of writing a style guide from scratch, adopt an existing one and make changes as needed. You’ll want a style guide for general JavaScript as well as a style guide for Angular.

There are numerous JavaScript style guides to choose from. Among the most popular are the Airbnb JavaScript Style Guide, the jQuery JavaScript Style Guide, and the Idiomatic Style Guide. It matters less which one you choose than it does to establish clear guidelines for your team.

The best guidance for Angular applications is the “Angular 1 Style Guide,” edited by John Papa. This style guide has contributions from the core Angular team and has earned their endorsement.

If your project is based on AngularJS or higher and ES2015, another style guide to consider is Todd Motto’s "AngularJS Style Guide.” Changes in AngularJS (component() and its related lifecycle hooks) and ES2015 (e.g., module imports, class syntax) contribute to there being “good parts” of Angular that work best for ES2015 applications. This guide is especially useful for applications that are slated for migration to Angular.

Tip

Style guides reflect the wisdom of many years of experience. Good style guides explain the “whys” of each rule, making them invaluable for educating yourself about the use of the language.

Use an IDE that Supports EditorConfig

Developers are stubborn. Mandating that all members of a team use the same editor is an exercise in frustration. Instead of fighting against competing editors, you can achieve the goals of uniform code appearance while supporting your developer’s choices by adding an EditorConfig file to your project.

EditorConfig is a project that promotes a cross-editor configuration file for specifying character sets, indentation, and whitespace style. As the project matures, we’ll see more properties such as brace indentation style and quote type being used.

Most popular editors support EditorConfig natively or through a plug-in, giving your developers a wide choice of editors to pick from. Editors detect the configuration file automatically and will use it over the default configuration for the editor itself.

Use Automated Tools to Build and Validate Your Applications

Once your project has adopted uniform style guidelines, you’ll need some method to automatically enforce the rules. Fortunately there is plenty of tooling to choose from to meet the needs of any project size.

Two popular build tools are Grunt and Gulp. Each features a rich plug-in ecosystem for running tasks, bundling source code, compiling CSS, running unit tests, and more. Both can be added to an existing project without needing to make changes to the project’s source code. Grunt favors configuration files for defining tasks, whereas Gulp is more scripting based.

In 2016, Webpack emerged as the most recommended build tool for medium to large projects. Webpack can serve an application, watch for changes to individual modules and immediately load them (hot module replacement), transpile ES2105 code to ES5, resolve module dependencies, and more. Webpack is a heavier-weight tool that can handle many tasks, but it requires more effort to configure than Gulp or Grunt; therefore Webpack may be a good choice for building a whole web application, but is probably overkill for managing small libraries or components.

For smaller projects it’s possible to eschew these build tools altogether by using individual command-line tools and configuring small npm run scripts in the project’s package.json file. As the build chain grows in complexity, this approach becomes difficult to manage, but it’s perfectly adequate for build chains that have few steps.

Whichever tool you use, it should be configured to automatically run linting and (optimally) unit tests each time a file changes. Developers will be immediately alerted to deviations from the style guide and will know whether their changes have caused any unit tests to fail.

As the size of a project grows, the process of linting, testing, and building may start to slow. This is a sign that your project contains too many responsibilities. Look for opportunities to divide features into their own projects and reimport them as dependencies for your main project.

Code and Style Linters

Linters are programs that read source code and output error messages if the source code does not comply with the linter’s style rules. Using any linter is better than none, but the most powerful choice today is Nicholas Zakas’ ESLint. ESLint rules are configurable via plug-ins. The open source community has contributed a large library of rules reflecting best practices for writing JavaScript in various environments, including a plug-in for linting Angular applications. ESLint 3.0 and later will incorporate functionality in JSCS, the JavaScript Code Style linter.

If your project already makes use of a JavaScript linter, there’s no urgent need to migrate to ESLint. Otherwise, there is no need to compare other linters. Each generation of linters has built upon ideas previously introduced. ESLint can do what other linters can do and more.

Summary

In this section we covered:

• General best practices for writing web applications and the benefits of uniformity and consistency in reducing effort in understanding code

• Tools that help ensure best practices by automating code and style guideline conformity