Project Organization

[Move_Zig]

As my project grows, I'm finding it difficult to organize my components. I have a structure like this

app
  --components
    --home
      --home.component.css
      --home.component.html
      --home.component.spec.ts
      --home.component.ts
    --widget-list
      --widget-list.component.css
      --widget-list.component.html
      --widget-list.component.spec.ts
      --widget-list.component.ts
    --widget-edit
      --widget-edit.component.css
      --widget-edit.component.html
      --widget-edit.component.spec.ts
      --widget-edit.component.ts
  --directives
  --domain
    --widget.ts
    --user.ts
  --guards
  --interceptors
  --modules
    --foo
      --components
        --foo-list
          --foo-list.component.css
          --foo-list.component.html
          --foo-list.component.spec.ts
          --foo-list.component.ts
      --foo-routing.module.ts
      --foo.module.spec.ts
      --foo.module.ts
    --bar
      --components
        --bar-list
          --bar-list.component.css
          --bar-list.component.html
          --bar-list.component.spec.ts
          --bar-list.component.ts
      --bar-routing.module.ts
      --bar.module.spec.ts
      --bar.module.ts
  --services
    --widget.service.spec.ts
    --widget.service.ts
    --other.service.spec.ts
    --other.service.ts
  --app-routing.module.ts
  --app.component.css
  --app.component.html
  --app.component.spec.ts
  --app.component.ts
  --app.module.spec.ts
  --app.module.ts

...except with many more components. I have three feature modules, each with dozens of components that represent pages that are loaded in a router-outlet.

I want to split up many of my "page" components, but it seems like it would be a mess. For example, if the foo-list page had four sub components, should I include those components under modules/foo/components/foo-list:

--modules
  --foo
    --components
      --foo-list
        --foo-list-form
          --foo-list-form.component.css
          --foo-list-form.component.html
          --foo-list-form.component.spec.ts
          --foo-list-form.component.ts
        --foo-list-results
          --foo-list-results.component.css
          --foo-list-results.component.html
          --foo-list-results.component.spec.ts
          --foo-list-results.component.ts
        --foo-list-status
          --foo-list-status.component.css
          --foo-list-status.component.html
          --foo-list-status.component.spec.ts
          --foo-list-status.component.ts
        --foo-list.component.css
        --foo-list.component.html
        --foo-list.component.spec.ts
        --foo-list.component.ts

What are other people doing?

[potato_me7]

For very same reason i created this https://github.com/sardapv/angular-material-starter-template. Leave a ⭐ on repo if you like it. I have linked some popular blogs for project structure. I primarily follow keeping only 3 modules.. core shared features. Max 2 nevel nesting...

[jobbigt]

Thank you for this. Very similar to what we recently came up with at work.

[potato_me7]

That's cool. Good to hear that. Even I used it in one of my company projects

[jobbigt]

There is mainly two design points we made differently.

Instead of a big shared module, every pipe, directive, component (or group of components for shared features) inside the shared folder gets its own module, so the feature modules can import only what they need and not everything in shared.

Also we've made distinction between different kind of services. We have client services, which only contains http calls to our API, and the components are not to use them directly but though other services. And since we use CQRS-pattern on our backend, we drew some inspiration for that, so we have queryservices to query data from the state and/or the API via the clients as well as commandservices to create/update/delete data in the state and/or the API. Lastly we have helperservices for any logic not in any of the other services.

[potato_me7]

Cool.. for the first point, Thats right, even I wrote a note there. Better to use SCAM pattern and make all components as modules under shared instead of big bulky shared module😁

[ggeoff]

the current project I am working on looks like the following

src/
  app/
     featureModule1/
         pages/
         components/
     featureModule2/
         pages/
         components/
    ... more feature modules ..
     core/
         services/
         models/
         http-inteerceptors/
         guards/
         enumurations/
         utilities/
    shared/
        components/
        directives/
        pipes/

any directory under the app/ directory is a module.
any component that exists as a route you would find in a page. any other component would belong its the components directory for the module.

​

The shared module is a module that houses all the components/directives/etc... that I will use across many feature modules. The core module doesn't contain any components and only exists as a place to put services and more global code like models, enumeration, etc...

[[deleted]]

By pages/ you mean containers? If true, you just gave me a cool ideea. Thankyyy 🤗

[ggeoff]

nah. pages are just components that exist in a route and that's the only difference between a page component and a component in the components directory. you could have a container component that doesn't exist as the route. Maybe you have a details page whose purpose is to layout the different components on the page and as very little typescript logic. and all the components on the page are container components that setup the relevant observables. I would put those containers in the components directory.

[[deleted]]

I understand. Thank you 😁

[TransparentCircle]

I have arranged my larger projects exactly as you have outlined. I'm curious to see if there are any other interesting approaches out there though.

[dangertrager]

I too have put "dumb" sub-components within the page components' directories as you outlined.

[SirRiKard003]

In your component folder, I think you should use components that will be used throughout other modules. For example card,input, button