Angular Best practices!

It is known in the developer word that not following best practices can create major issues in usage of a framework.Angular is no exception.

In this blog post, I will highlight some best practices that I have picked up.

File Naming and Folder structure – 

Use the angular cli for creating components, services etc.It will create them in a proper format.

Component files should be of the following format –





Service names will be of the format –


Component files of a particular component should have their own folder.The services of a particular module can be bunched together and put inside a service folder.

Single Responsibility Principle – 

This principle states that every module/class should have responsibility over a singular part of functionality provided by the software & responsibility should be encapsulated inside the class.

This essentially means that we should break down components, services etc w.r.t what responsibility we assign them.A service that deals with api communication should not deal with sorting data inside a table.

Symbol Naming Best practices – 

  • selector and class names of the same component should be similar
  • for naming camel case is to be used
  • component and service name should have suffixes of Component and Service respectively to define what they are at a glance
  • for service and component class names upper camel case i.e. Pascal case should be used. ex – NavigatorComponent
  • variable and function names should be lower camelCase i.e. tempName

Imports ordering – 

3rd party imports should be given in the beginning.Then imports from own app should be given.


Instead of directly updating variables, try to use Object.assign to update the variables.This allows to avoid certain problems.





Function Size

The size of funtions should be 5 to 10 lines.If they are larger than that, they should be broken down to more functions.


Essentially, an Angular project should have these 3 parts as separate modules to allow scalability and reuse.

Core Module – This should contain all shared singleton services and app level components.

Shared Module – This should contain all shared components,directives,pipes

Feature Module – this should contain all feature level components,services,pipes

Prefix you selector

Selectors should be prefixed with 2 to 4 characters to denote which module they belong to, so it doesn’t conflict with another module that may have something similar.

Component Structure

Html,Css and Typescript files should be separate for a given component.They should not be done inside the typescript file.

Components should have only simple logic.Complex logic should be extracted and placed inside services.

private variables should be declared after public variables.Same goes for functions.

Few points about services

Api call related code should be extracted and kept in services.

Services should not be put inside lazily loaded modules, as their instance wont be created in the same manner as services declared in the core module.


AOT compilation should be used as it dramatically reduces the distribution size.

Modules that aren’t always used should be lazily loaded.

Use Source-map-explorer to check the sizes of the compiled distribution files and correspondingly reduce them.













Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s