Discussion on: 7 Deadly Sins of Angular

View post

Great post! I agree with everything except point #6.

I am a big fan of organizing per type of class and works really well for me, especially in terms of code reusability. Sure, there may be a specific service bound to a specific component, or a pipe you only use in one component...but, in general, I try think very generic and favor reusability.

Lars Gyrup Brink Nielsen • Mar 30 '21

Natalia Venditto • Apr 3 '21

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

Lars Gyrup Brink Nielsen • Apr 3 '21 • Edited

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

Natalia Venditto • Apr 3 '21 • 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.

Lars Gyrup Brink Nielsen • Apr 4 '21 • 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

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

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

Natalia Venditto • Apr 5 '21

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!

Lars Gyrup Brink Nielsen • Apr 5 '21 • 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.

Natalia Venditto • Apr 5 '21

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

That was my point.