There’s a pattern/mindset/delusion known as “smart” and “dumb” components. The idea is that smart components understand some domain knowledge (they understand and process the data they’re responsible for), while dumb components do nothing but present data their parent component gives to them (as inputs) and report data back to their parent that the user gives to them (as outputs).

I think this is wildly stupid. I think this leads to unnecessary “prop drilling,” super heavy “smart” components, and ultimately makes your code harder to change later.

But instead of just complaining, I’ll tell you how I architect Angular applications.

First, here’s how I think of Angular constructs:

Next, I have a simple policy - laser focus. A component should focus on one reasonable, useful interaction and/or presentation. A service should focus on one reasonable, useful data set.

Each component and each service should have a well thought out purpose.

I go one step further and also make use of Injection Tokens to provide shared data (as opposed to shared logic). So I end up with:

With this basic idea I’ve found that I’m able to get architectures that are highly decoupled, highly focused, extremely easy to test, and super easy to change later.

Another thing I take advantage of is providing services and injection tokens at the route and component levels. This allows me to be very intentional with my designs.

Now, these ideas are nothing novel. We’re talking Engineering 101 principles here. Breaking your system down into smaller, highly-focused subsystems. Angular gives us clear constructs to do this.

Quit wasting time with “smart” and “dumb” components. Use the basic ideas I’ve outlined here and you’ll thank yourself later.