Application Structure and Best Practices Of Angular — Part 2

Ankita Joshi
Jan 6 · 6 min read
Image from

This is part 2 of Angular best practices, in the first part we learn about Angular CLI, modular structure of Angular application, lazy loading, and lifecycle hooks of angular (detailed story here).

In this part, we will look into the folder structure and nomenclature, coding styles of Angular applications. For a better understanding of code, we need this thing in our life.

Folder Structure of Angular Application —

By default, angular provides us basic file structure as below when we run the command, which will create a new application skeleton with all new structures.

ng new sample-project

The skeleton is for a simple Welcome application that is ready to run and easy to modify.

First of all, we will see CLI configuration context, which means related to all internal configurations of the angular application.

.editorconfig— Configuration for code editors for all developers working on applications.

.gitignore— Specifies files to be intentionally untracked that git should ignore.— Introductory documentation for the application.

package.json— Provides all npm package dependencies (node modules) that are needed by the application.

package-lock.json— Provides version information for all packages installed into node_modules by the npm client. Changes over npm install command run for application.

angular.json— CLI configuration defaults application, including configuration options for versions of the application, build, serve, and test tools that the CLI uses. Which style is application using and all.

tsconfig.json— The base typescript configuration for the application.

src/— Source files for the application.

node_modules/— Provides npm packages to the application. node_modules dependencies are visible to all.

Application Project Files —

By default, the CLI command ng new sample-project creates an application folder named "sample-project" and generates a new application skeleton in a src/ folder at the top level of the application. This newly generated src/ folder contains one default component called AppComponent. Files related to AppComponent are present therein src/app/ folder. Which will contain the root module, component, and template.

We can use the ng generate command on the command line to add functionality and data to the application, like components, modules, directives, services, pipes, etc.

Subfolders of src/ contain the application source and application-specific configuration. Files at the top level of src/ known as Application source files which support testing and running your application. We will see details of files and folders in src/ (refer to image above showing the file structure of the angular application).

app folder —

Contains the component files in which your application logic and data are defined. Angular components, templates, and styles go in here.

app/app.module.ts — This file defines the root module, named AppModule, that tells the Angular flow of the application. Initially declares only the AppComponent. As you add more components or modules to the app, they must be declared here.

app/app.component.ts— This file defines the logic for the application's root component, named AppComponent. This component by default added by ng new sample-project, rather every new application will have AppComponent.

app/app.component.html — This file defines the HTML template associated with the root AppComponent.

app/app.component.less — This file defines the base CSS stylesheet for the root AppComponent. If you or choosing any other style then the file will be for that style. Like app.component.css.

app/app.component.spec.ts — This file defines a unit test for the root AppComponent.

Assets Folder —

assets/ contains images, logos, and other asset files which you want publicly available and to be copied as-is when you build your application.

Environments Folder —

environments/contains build configuration options environments. By default, there is an unnamed standard development environment and a production environment. You can define additional target environment configurations like staging.


favicon.ico is an icon to use for this angular application in the bookmark bar or browser tab.


index.html is the main and first HTML page that is served when our angular application site loads.


main.ts is the main entry point of our angular application. It compiles the application with the JIT compiler and bootstraps the application's root module (here it is AppModule) to run in the browser. You can also use the AOT compiler without changing any code by appending the --aot flag to the CLI build and serve commands.


This file includes polyfills needed by Angular and is loaded before application. Also provides polyfill scripts for browser support.


styles.less is lists CSS/LESS files that supply styles for a project. Also, we can include global style here directly using the class name.


test.ts is a file required by karma.conf.js and loads recursively all the .spec and framework files. This is the main entry point for your unit tests, with some Angular-specific configuration. You don't typically need to edit this file.

All above is the default folder structure of the application provided by Angular itself. This folder structure is very good to use for all your application as this is globally used by almost all developers, so others can better understand your code.

While using this folder structure we can have our components(which will be required by our application and will be added later after generating the application) should be listed like below.

In general, we need to use the CLI command — ng generate component compoenent-name which will help us to maintain continuity in an application.

For example — In the below image we can see the logistics folder. In which we have types of logistics in a different folder. Like this, we can maintain components differently for our application. These components will list out in the root module that is AppModule. If we have many components then we can make a different module and list them in AppModule. For example, we can make LogisticsModule to define all components, services in one place for logistics with ease.

Also, in the above image, we can learn nomenclature though. Let’s see how —

We can use consistent names for all features. We should follow a pattern that describes the feature then its type. The recommended pattern is feature.type.ts.

If the file feature name contains multiple words in it then do use dashes to separate words in between.

Do use conventional type names including .service, .component, .pipe, .module, and .directive.

For component, the file name should contain .component in it. And the component name should have a prefix Component like LogisticsComponent.

For service, the file name should contain .service in it. And the service name should have a prefix Service like LogisticsService. A good is to use a single service file for the whole application. Which will be useful to reuse the code. That can be placed in the root folder.

Now let’s discuss about coding style in Angular

Our coding should be cleaner, easier to read and maintain, and more testable for better understanding and acknowledgment. To achieve this we should apply the single responsibility principle for our coding in the Angular application.

One file should define one thing at a time that is component, service, pipe, etc.

Each file should have a limit of at least 400 lines. The key is to make the code more reusable, easier to read, and less mistake-prone.

Each function of the component should as small as possible (we can put our limit to 75 lines or so). Small functions are easier to test, especially when they do one thing and serve one purpose. Small functions are promoting reuse, easier to read, easier to maintain.

Do use dashed-case or kebab-case for naming the element selectors of components.

Conclusion — Here we have learned the basics of the coding style of angular which will help normally to build applications.

References —


A Bespoke Engineering Studio