Angular project structure best practice

This is the directory structure of my Angular project. Angular applications can get big with many different types of components. What is the best practice for organizing Angular applications?

-app
  -layout
     -home-layout
         -header
         -menu
         -content
            -detail-page
               -left-side
                  -left-side.component.html
                  -left-side.component.ts
               -right-side
             -detail-page.component.html
             -detail-page.component.ts
         -footer
     -pipes
     -widget-features
  -material-module
  -services
  -models

With the actual structure, the site map organization is very clear, I can easily find the different pages content.

But to get a modular architecture, I want to reorganize the structure.

Can you give me some advises, please?

Remember there is no magic bullet for this or a general recipe which fits for all projects.

That said, you could use the official Angular Style Guide, which tries to follow the Folders-by-feature structure.

Regarding the Application structure, you have to keep in mind being LIFT:

> Do structure the app such that you can Locate code quickly, Identify > the code at a glance, keep the Flattest structure you can, and Try to > be DRY

• Locate

> Do make locating code intuitive, simple and fast.

• Identify

> Do name the file such that you instantly know what it contains and > represents. > > Do be descriptive with file names and keep the contents of the file to > exactly one component. > > Avoid files with multiple components, multiple services, or a mixture.

• Flat

> Do keep a flat folder structure as long as possible. > > Consider creating sub-folders when a folder reaches seven or more > files. > > Consider configuring the IDE to hide distracting, irrelevant files > such as generated .js and .js.map files.

• Try to be DRY

> Do be DRY (Don't Repeat Yourself). > > Avoid being so DRY that you sacrifice readability.

---

According to the structure you have shown, one thing might be worth reviewing is the level of folders nesting following the principle "Do keep a flat folder structure as long as possible".

This means you should keep the structure as flat as possible, this makes possible to locate the files faster. But this is not a must rule, but a should one. So, if making the structure flatter doesn't affect your current logical organization, you probably should make it flatter (otherwise don't).

Remember this aims to improve the development process. If something is not improving your team organization/productivity, etc., then don't use it, if it helps, use it.

I like the structure recommended at this Medium article: Angular folder structure, but with some modifications we, at my company, ended up with the below:

-app
  
 -shared
     -services
     -pipes
     -components
     -models

-modules
  -users
	-components
		-list
		-edit
	-models
		-users.model.ts
	-services
		-user-service.ts

	users.component.ts // this component should act like a container/smart component
	users.component.html
	users.module.ts
	users.route.ts

  -organisations
	-components
		-list
		-manage
	-models
		organisation.model.ts
	-services
		organisation.service.ts
		
	organisations.component.ts  // this component should act like a container/smart component
	organisations.component.html
	organisations.module.ts
	organisations.route.ts

-app.component.ts
-app.component.html
-app.module.ts
-app-routing.module.ts

This also gives a kind of micro-service architecture where each module/feature having its own services/dependencies.

The architecture that the Angular Style Guide leans towards is known as a 'feature module' architecture, where features are encapsulated within Angular modules (TypeScript classes with an @NgModule decorator).

To get a feel for it, try running some generate commands using the Angular CLI.

For example, to create a feature module containing some encapsulated components/services, run these commands in sequence:

ng g m my-awesome-feature
ng g c my-awesome-feature/cool-component
ng g s my-awesome-feature/fancy-service

The CLI will create a nice module architecture for you, and even automatically declare your components in the module files!

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { CoolComponentComponent } from './cool-component/cool-component.component';

@NgModule({
  imports: [
    CommonModule
  ],
  declarations: [CoolComponentComponent]
})
export class MyAwesomeFeatureModule { }

I always follow a similar structure, that combines the best of url-based structure and modular architecture, in my opinion. It's something like this:

• app
  • _models
  • _services
  • _shared
    • shared components
    • shared modules
  • home
  • whatever page
    • whatever's specific components

Basically, in "_shared" you would put all the components and modules shared among different pages, such as a footer or the Material modules. You must declare them or import them in the _shared module, as well as export them.

I'm assuming that all the services are shared and provided in the app module, but of course you could put them in the _shared module or in any other child's module.

By the way, I name them with an actual underscore so that they bubble up in the explorer. It's handy to know they're always gonna be up there.

Here is an entire article from medium where you will find useful advice for your angular project.

1. Use a Shared Module: In short, when using a Shared Module: DO declare components, pipes, directives, and export them. DO import FormsModule, ReactiveFormsModule, and other (3rd-party) modules you need. DO import the SharedModule into any other Feature Modules. DO NOT provide app-wide singleton services in your SharedModule. Instead, move these to the CoreModule. DO NOT import the SharedModule into the AppModule.

2. Use a Core Module: In short, when using a Core Module: DO import modules that should be instantiated once in your app. DO place services in the module, but do not provide them. DO NOT declare components, pipes, directives. DO NOT import the CoreModule into any modules other than the AppModule.

3. Simplify your imports:

4. Shorten your relative paths

5. Use SCSS Variables

As a way in my project I generally choose below structure in my projects. Difference between modules components and shared components is that shared ones used in all modules but module's component one is just related that module.

Example shared components : ModalComponent, LoaderComponent etc...

• app
  • core
    • services
    • interceptors
    • guards
    • models
    • helpers
  • modules
    • x module
      • components
      • pages
    • y module
      • components
      • pages
  • shared
    • components
    • header
    • footer
    • directives
    • pipes