Falling in ♥ with MEAN: Angular 4 : Getting started and best practices

I have started using Angular4 for my product TapestryKPI. I have spent couple of weeks trying to setup the base framework for the migration. Throughout the demos I have shown, I document what I have learned as best practice. These practices work for my team and may also help you if you migrate or write your applications in Angular 4.

1) Using Angular-CLI

Every production ready code needs bundling. Bundling our code in AngularJS involved using ember, webpack and yeoman. With the latest version, angular shipped its own CLI named Angular CLI. It helps us create the basic app with basic architecture, setup typescript, enable live reload, build, code analysis, run unit tests,run end to end tests and deploy our code. We need to have nodejs installed to have angular-cli. The installation happens from npm.

2) Using Visual Studio Code and installing ‘angular2-useful-dev-extensions’, ‘Angular v4 TypeScript Snippets’

Visual studio code has lots of extensions that enable auto complete and code completion. angular2-useful-dev-extensions install a set of plug-ins that help us stay productive with angular. Generating angular snippets are automated using ‘Angular v4 TypeScript Snippets’ plug-in.


3) Installing codelyzer

Codelyzer helps us suggest best practices during writing angular code.


4) Some best practices from the Angular team

a) Break everything into components. Appmodule should be at the root of your application.

Modularize your use case to make widgets. A widget contains an angular component, its template and style.


b) Each component and template should not exceed 400 lines,

c) Make functions smaller. The maximum lines on a function should not exceed 10–15 lines ( derived from Uncle Bob’s clean code)

d) Use consistent name for all assets. Make classes upper camel case. Class name should be noun and method names should be verb.

e) Append symbol name with conventional suffix. ( for example, the login component can be named as LoginComponent with Component suffixed).


f) file name should have conventional suffix. For example, a component can have its name suffixed with component.


g) use lower camel case for naming selectors and components

h) separate words with hyphens in selectors.


i) The best way to store bootstraping and platform information is main.ts.

j) configure your components to use logger. Use proper error handling.

k) Unit testing is mandatory and the test spec file should have the same name as the component name.


l) Do not use capital letters for constants. Use lower camel case instead.

m) Do not use data type names while naming properties. ‘strusrename’ is wrong and ‘username’ is correct.

n) Stop prefixing interfaces with ‘I’. It is a typescript best practice as some predefined interfaces use I during compilation.

o) use classes instead of interfaces. In ES5 and above only classes exist and even though we write interfaces, it will be converted to classes.

p) Import line spacing. Leave an empty line between angular imports and custom imports


q) follow the LIFT principle ( Locate your code quickly, Identify the code easily, Flattest structure, Try DRY.

r) Use lazy loading on subcomponents and where ever possible.

There are other best practices suggested by Angular. We do experiment Angular with Typescript and we found Typescript has its own best practices. Some of them collide and create conflicts on what to use. For example, string should use double quotes in Typescript but as per angular, single quotes is acceptable (something errors while trying). Deciding what to use and what not to use depends on the type of business and experts advise in the team. We at Tapestry brainstorm when ever we want to set some standards.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.