DEV Community

Discussion on: 7 Deadly Sins of Angular

Collapse
layzee profile image
Lars Gyrup Brink Nielsen

Collapse
anfibiacreativa profile image
Natalia Venditto

Well, I don't consider it sin, Lars. :)

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen • Edited

It's the deadliest sin of them all if you ask me 😃

Thread Thread
anfibiacreativa profile image
Natalia Venditto • Edited

To each their own. ;) Or perhaps we are talking about different use cases, because I can't believe you violate DRY or create cross component dependencies, which is effectively the deadliest sin I can think of.

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen • Edited

In an application, I would insist on group by feature:

src/
- app/
  - admin/
    - admin-dashboard.component.ts
    - manage-crises.component.ts
  - auth/
    - auth.service.ts
    - login.component.ts
  - crisis-center/
    - crisis.service.ts
    - crisis-center.component.ts
  - heroes/
    - hero.service.ts
    - hero-list.component.ts
Enter fullscreen mode Exit fullscreen mode

not group by type:

src/
- app/
  - components/
    - admin-dashboard.component.ts
    - crisis-center.component.ts
    - hero-list.component.ts
    - login.component.ts
    - manage-crises.component.ts
  - services/
    - auth.service.ts
    - crisis.service.ts
    - hero.service.ts
Enter fullscreen mode Exit fullscreen mode

Grouping by type quickly gets out of hand and violates the Principle of Proximity. It doesn't scale well and lowers maintainability.

Thread Thread
anfibiacreativa profile image
Natalia Venditto

I am not really with energy enough to have a very long discussion on this, and appreciate your opinion, but do not share it at a 100%. Usually all services inherit (or should, from a base) and that base needs a common place to be. Some services are shared between several domains, and they also need a common place to be at. Creating cross domain dependencies is a far worse issue. The principle of proximity admits exceptions. This scenario is valid for a small to medium sized application. For an enterprise application, rewriting the same code snippets over and over to maintain them in proximity, will cause you a real maintenance issue.

Also my impression is that people need to get better at browsing with their IDE's. And I mean by class and by code inside a folder.

We can't always agree, Lars. :D We do on other items though!

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen • Edited

Interesting, I rarely find the need to use inheritance. I favor composition over inheritance. It's got a much looser coupling.

Classes that are shared between feature or domains can live in libraries or folders inside of a shared grouping folder.

About DRY, I think it's generally being used too much as an excuse without considering it's trade-offs. An abstraction made too early can become very expensive and difficult to undo later in a project's life span.

Thread Thread
anfibiacreativa profile image
Natalia Venditto

"Classes that are shared between feature or domains can live in libraries or folders inside of a shared grouping folder."

That was my point.