Refactoring Angular Applications

Chapter 6. Views and Templates

Up to this point the refactoring discussed covered general principles for producing clean code, creating clear separation of concerns, and organizing code so that it’s easier to read and understand. The next four sections will cover refactoring techniques that are particular to Angular and therefore require a deeper understanding of it than the previous sections.

Starting a new Angular application based on a designer’s prototype can lead to a tangle of application responsibilities within one template. You can see this happening when one template contains differing responsibilities (e.g., navigation, login, branding, and application widgets).

There are often competing developer roles contributing to the content of a template. One is the designer responsible for the general look and feel of the application. The designer mainly writes the HTML and the CSS. The other is the programmer who adds the interactive and dynamic elements of the applications. Both of these contributors need to modify the templates and it’s easy to step over the other’s work. This problem is compounded when the template contains many responsibilities.

Another cause of tangled template responsibilities arises by designing the application as though it were a series of screens or pages. More on this antipattern and how to recover from it is explained in the section Refactoring to Patterns.

The best way to address this problem is to avoid putting all of your application’s responsibilities ...