Angular project structure best practice [closed]

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, Identifythe code at a glance, keep the Flattest structure you can, and Try tobe DRY

• Locate

Do make locating code intuitive, simple and fast.

• Identify

Do name the file such that you instantly know what it contains andrepresents.

Do be descriptive with file names and keep the contents of the file toexactly 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 morefiles.

Consider configuring the IDE to hide distracting, irrelevant filessuch 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-featureng g c my-awesome-feature/cool-componentng 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 { }