Angular project structure best practice

Question

Can someone give me some suggestions about my project structure, please?

-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?

Answer 1

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.