STYLE File structure conventions Some code examples display a Kle that has one or more

similarly named companion Kles. For example, hero.component.ts and

hero.component.html . The guideline will use the shortcut hero.component.ts|html|css|spec
to represent those various Kles. Using this shortcut makes this guide's Kle structures easier
to read and more terse. Table of contents 1. Single responsibility 2. Naming 3. Coding
conventions 4. App structure and Angular modules 5. Components 6. Directives 7. Services
8. Data services 9. Lifecycle hooks 10. Appendix Single responsibility Apply the Single
Responsibility Principle (SPR) to all components, services, and other symbols. This helps
make the app cleaner, easier to read and maintain, and more testable. Rule of One Rule of
One avoid have an unmistakeable red header. STYLE 01-01 The key is to make the code
more reusable, easier to read, and less mistake prone. The following negative example
deKnes the AppComponent , bootstraps the app, deKnes the Hero model object, and loads
heroes from the server ... all in the same Kle. Don't do this. app/heroes/hero.component.ts
1. /* avoid */ 2. 3. import { platformBrowserDynamic } from '@angular/platform-
browserdynamic'; 4. import { BrowserModule } from '@angular/platform-browser'; 5.
import { NgModule, Component, OnInit } from '@angular/core'; 6. 7. class Hero { 8. id:
number; 9. name: string; 10. } 11. 12. @Component({ 13. selector: 'my-app', Do deKne one
thing, such as a service or component, per Kle. Consider limiting Kles to 400 lines of code.
Why? One component per Kle makes it far easier to read, maintain, and avoid collisions
with teams in source control. Why? One component per Kle avoids hidden bugs that often
arise when combining components in a Kle where they may share variables, create
unwanted closures, or unwanted coupling with dependencies. Why? A single component
can be the default export for its Kle which facilitates lazy loading with the router. COPY
CODE 14. template: ` 15.

{{title}}
16.
{{heroes | json}}
17. `, 18. styleUrls: ['app/app.component.css'] 19. }) 20. class AppComponent implements
OnInit { 21. title = 'Tour of Heroes'; 22. 23. heroes: Hero[] = []; 24. 25. ngOnInit() { 26.
getHeroes().then(heroes => this.heroes = heroes); 27. } 28. } 29. 30. @NgModule({ 31.
imports: [ BrowserModule ], 32. declarations: [ AppComponent ], 33. exports: [
AppComponent ], 34. bootstrap: [ AppComponent ] 35. }) 36. export class AppModule { }
37. 38. platformBrowserDynamic().bootstrapModule(AppModule); 39. 40. const HEROES:
Hero[] = [ 41. {id: 1, name: 'Bombasto'}, 42. {id: 2, name: 'Tornado'}, 43. {id: 3, name:
'Magneta'}, 44. ]; 45. 46. function getHeroes(): Promise { 47. return
Promise.resolve(HEROES); // TODO: get hero data from the server; 48. } It is a better
practice to redistribute the component and its supporting classes into their own, dedicated
Kles. As the app grows, this rule becomes even more important. Back to top Small
functions STYLE 01-02 1. import { platformBrowserDynamic } from '@angular/platform-
browserdynamic'; 2. 3. import { AppModule } from './app/app.module'; 4. 5.
platformBrowserDynamic().bootstrapModule(AppModule); Do deKne small functions
Consider limiting to no more than 75 lines. Why? Small functions are easier to test,
especially when they do one thing and serve one purpose. Why? Small functions promote
reuse. Why? Small functions are easier to read. Why? Small functions are easier to
maintain. Why? Small functions help avoid hidden bugs that come with large functions that
share variables with external scope, create unwanted closures, or unwanted coupling with
dependencies. Back to top Naming Naming conventions are hugely important to
maintainability and readability. This guide recommends naming conventions for the Kle
name and the symbol name. General Naming Guidelines STYLE 02-01 Back to top
Separate Jle names with dots and dashes STYLE 02-02 Do use consistent names for all
symbols. Do follow a pattern that describes the symbol's feature then its type. The
recommended pattern is feature.type.ts . Why? Naming conventions help provide a
consistent way to Knd content at a glance. Consistency within the project is vital.
Consistency with a team is important. Consistency across a company provides tremendous
efKciency. Why? The naming conventions should simply help Knd desited code faster and
make it easier to understand. Why? Names of folders and Kles should clearly convey their
intent. For example, app/heroes/hero-list.component.ts may contain a component that
manages a list of heroes. Back to top Symbols and Jle names STYLE 02-03 Do use dashes
to separate words in the descriptive name. Do use dots to separate the descriptive name
from the type. Do use consistent type names for all components following a pattern that
describes the component's feature then its type. A recommended pattern is feature.type.ts .
Do use conventional type names including .service , .component , .pipe , .module , and
.directive . Invent additional type names if you must but take care not to create too many.
Why? Type names provide a consistent way to quickly identify what is in the Kle. Why?
Type names make it easy to Knd a speciKc Kle type using an editor or IDE's fuzzy search
techniques. Why? Unabbreviated type names such as .service are descriptive and
unambiguous. Abbreviations such as .srv , .svc , and .serv can be confusing. Why? Type
names provide pattern matching for any automated tasks. Do use consistent names for all
assets named after what they represent. Do use upper camel case for class names. Do match
the name of the symbol to the name of the Kle. Do append the symbol name with the
conventional sufKx (such as Symbol Name File Name app.component.ts
heroes.component.ts hero-list.component.ts hero-detail.component.ts validation.directive.ts
@Component({ ... }) export class AppComponent { } @Component({ ... }) export class
HeroesComponent { } @Component({ ... }) export class HeroListComponent { }
@Component({ ... }) export class HeroDetailComponent { } Component , Directive ,
Module , Pipe , or Service ) for a thing of that type. Do give the Klename the conventional
sufKx (such as .component.ts , .directive.ts , .module.ts , .pipe.ts , or .service.ts ) for a Kle
of that type. Why? Consistent conventions make it easy to quickly identify and reference
assets of different types. app.module.ts init-caps.pipe.ts user-proKle.service.ts Back to top
Service names STYLE 02-04 @Directive({ ... }) export class ValidationDirective { }
@NgModule({ ... }) export class AppModule @Pipe({ name: 'initCaps' }) export class
InitCapsPipe implements PipeTransform { } @Injectable() export class UserProfileService
{ } Do use consistent names for all services named after their feature. Do sufKx a service
class name with Service. For example, something that gets data or heroes should be called a
DataService or a HeroService . Symbol Name File Name hero-data.service.ts
credit.service.ts logger.service.ts Back to top Bootstrapping @Injectable() export class
HeroDataService { } @Injectable() export class CreditService { } @Injectable() export
class Logger { } A few terms are unambiguously services. They typically indicate agency
by ending in "er". You may prefer to name a service that logs messages Logger rather than
LoggerService . Decide if this STYLE 02-05 main.ts Back to top Directive selectors
STYLE 02-06 1. import { platformBrowserDynamic } from '@angular/platform-
browserdynamic'; 2. 3. import { AppModule } from './app/app.module'; 4. 5.
platformBrowserDynamic().bootstrapModule(AppModule) 6. .then(success =>
console.log(`Bootstrap success`)) 7. .catch(err => console.error(err)); Do put bootstrapping
and platform logic for the app in a Kle named main.ts . Do include error handling in the
bootstrapping logic. Avoid putting app logic in the main.ts . Instead, consider placing it in a
component or service. Why? Follows a consistent convention for the startup logic of an
app. Why? Follows a familiar convention from other technology platforms. Do Use lower
camel case for naming the selectors of directives. Why? Keeps the names of the properties
deKned in the directives that are bound to the view consistent with the attribute names.
Back to top Custom preJx for components STYLE 02-07 app/heroes/hero.component.ts 1.
/* avoid */ 2. 3. // HeroComponent is in the Tour of Heroes feature 4. @Component({ 5.
selector: 'hero' 6. }) 7. export class HeroComponent {} Why? The Angular HTML parser is
case sensitive and will recognize lower camel case. Do use a hyphenated, lowercase
element selector value (e.g. admin-users ). Do use a custom preKx for a component
selector. For example, the preKx toh represents from Tour of Heroes and the preKx admin
represents an admin feature area. Do use a preKx that identiKes the feature area or the app
itself. Why? Prevents element name collisions with components in other apps and with
native HTML elements. Why? Makes it easier to promote and share the component in other
apps. Why? Components are easy to identify in the DOM. app/users/users.component.ts
app/heroes/hero.component.ts app/users/users.component.ts Custom preJx for directives
STYLE 02-08 1. /* avoid */ 2. 3. // UsersComponent is in an Admin feature 4.
@Component({ 5. selector: 'users' 6. }) 7. export class UsersComponent {} 1.
@Component({ 2. selector: 'toh-hero' 3. }) 4. export class HeroComponent {} 1.
@Component({ 2. selector: 'admin-users' 3. }) 4. export class UsersComponent {} Do use a
custom preKx for the selector of directives (e.g, the preKx toh from
app/shared/validate.directive.ts app/shared/validate.directive.ts Back to top Pipe names
STYLE 02-09 1. /* avoid */ 2. 3. @Directive({ 4. selector: '[validate]' 5. }) 6. export class
ValidateDirective {} 1. @Directive({ 2. selector: '[tohValidate]' 3. }) 4. export class
ValidateDirective {} Tour of Heroes). Do spell non-element selectors in lower camel case
unless the selector is meant to match a native HTML attribute. Why? Prevents name
collisions. Why? Directives are easily identiKed. Symbol Name File Name ellipsis.pipe.ts
init-caps.pipe.ts Back to top Unit test Jle names STYLE 02-10 @Pipe({ name: 'ellipsis' })
export class EllipsisPipe implements PipeTransform { } @Pipe({ name: 'initCaps' }) export
class InitCapsPipe implements PipeTransform { } Do use consistent names for all pipes,
named after their feature. Why? Provides a consistent way to quickly identify and reference
pipes. Do name test speciKcation Kles the same as the component they test. Do name test
speciKcation Kles with a sufKx of .spec . Why? Provides a consistent way to quickly
identify tests. Symbol Name File Name Components heroes.component.spec.ts hero-
list.component.spec.ts hero-detail.component.spec.ts Services logger.service.spec.ts
hero.service.spec.ts Klter-text.service.spec.ts Pipes ellipsis.pipe.spec.ts init-
caps.pipe.spec.ts Back to top End-to-End End-to-End (E2E) test Jle names STYLE 02-11
Why? Provides pattern matching for karma or other test runners. Do name end-to-end test
speciKcation Kles after the feature they test with a sufKx of .e2e-spec . Why? Provides a
consistent way to quickly identify end-to-end tests. Symbol Name File Name End to End
Tests app.e2e-spec.ts heroes.e2e-spec.ts Back to top Angular NgModule NgModule names
STYLE 02-12 Why? Provides pattern matching for test runners and build automation. Do
append the symbol name with the sufKx Module . Do give the Kle name the .module.ts
extension. Do name the module after the feature and folder it resides in. Why? Provides a
consistent way to quickly identify and reference modules. Why? Upper camel case is
conventional for identifying objects that can be instantiated using a constructor. Why?
Easily identiKes the module as the root of the same named feature. Do sufKx a
RoutingModule class name with RoutingModule . Do end the Klename of a
RoutingModule with -routing.module.ts . Why? A RoutingModule is a module dedicated
exclusively to conKguring the Angular router. A consistent class and Kle name convention
make these Symbol Name File Name app.module.ts heroes.module.ts villains.module.ts
app-routing.module.ts heroes-routing.module.ts Back to top