pantonis
pantonis

Reputation: 6507

Angular folder structure and component services

I have read many articles about Angular folder structure. It is still not clear to me where do we put component services. Shared services between components are put under shared. But what about a service that is used only by a component? Usually I put all my component logic into a service and leave the component with code relevant only to UI stuff. Which one is better to use:

Each component and its service into the same folder

.
├── app.component.html
├── app.component.ts
├── app.module.ts
├── app-routing.module.ts
└── shop
    ├── clients
    │   ├── clients.component.html
    │   ├── clients.component.ts
    │   ├── clients.component.css
    │   └── clients.service.ts
    ├── orders
    │   ├── orders.component.html
    │   ├── orders.component.ts
    │   ├── orders.component.css
    │   └── orders.service.ts
    ├── shop.module.ts
    └── shop-routing.module.ts                 

or all services of a module under a services folder

.
├── app.component.html
├── app.component.ts
├── app.module.ts
├── app-routing.module.ts
└── shop
    ├── clients
    │   ├── clients.component.html
    │   ├── clients.component.ts
    │   └── clients.component.css
    ├── orders
    │   ├── orders.component.html
    │   ├── orders.component.ts
    │   └── orders.component.css  
    ├── services
    │   ├── clients.service.ts
    │   └── orders.service.ts
    ├── shop.module.ts
    └── shop-routing.module.ts

Upvotes: 10

Views: 15850

Answers (4)

Nikhil Kapoor
Nikhil Kapoor

Reputation: 607

Personally, I'll prefer this architecture, Since everything related to clients is in client module.It is easy for someone new to get this architecture and it is predeicatble.

--app.component.html
--app.component.ts
--app.module.ts
--app-routing.module.ts
--shop
------clients
--------clients.component.html
--------clients.component.ts
--------clients.component.css
--------clients.service.ts
------orders
--------orders.component.html
--------orders.component.ts
--------orders.component.css
--------orders.service.ts
----shop.module.ts
----shop-routing.module.ts

Apart from this, the architecture is for own ease...

My current architecture is like

--app.component.html
--app.component.ts
--app.module.ts
--app-routing.module.ts
--pages
----- About
-------- Component
----------- Has Details
--------------Component.ts
-----------------Html
--------- Service
------------All services here
----- Contact US
-------- Component
----------- Details
--------------Component.ts
-----------------Html
-------- Models
------------Model.ts
--------- Service
------------All services here 
--Theme
---- Common components

Upvotes: 3

Bat0u89
Bat0u89

Reputation: 453

I prefer having services separately from components because the package structure for components will probably reflect where they are on the page visually for most apps. While for services you probably want to package "by domain/feature" https://medium.com/sahibinden-technology/package-by-layer-vs-package-by-feature-7e89cde2ae3a Also components needing their own folders doesn't help with navigation when you also have to cram services into the same folder structure.

Upvotes: 0

Mithil Mohan
Mithil Mohan

Reputation: 243

It is all about Semantics and Readability in my opinion. Just doing it in a way that suits you and your convenience won't make it a good practice. It should be easy for a newbie or substitute developer to figure out your method in not time, so you should probably focus on that.

Tips to keep in mind:

1) Services should be easily relatable and shouldn't create any confusion

2) Path navigation shouldn't become complex ( for eg: avoid cases of ../../../../ )

3) Shared services should be placed under a meaningful folder

I would say that the second method you suggested is the common standard followed.

Refer : https://itnext.io/choosing-a-highly-scalable-folder-structure-in-angular-d987de65ec7

Upvotes: 5

Nico
Nico

Reputation: 2021

I don't think there is a one size fit all for a folder structure as it is completely opinionated and really it's just a nice to have.

Some say we should group based on features.

Some say we should group based on similarities.

The list goes on...

I remember a guide from Dan Abramov the really speaks about how we should truly look at structuring our app. It can be found Here.

Simple but not simple just work with what you think is best.

Upvotes: 5

Related Questions