Disclaimer: These rules are what I currently believe to be generally applicable to Angular applications today (2023). These are based on my experience over the last year working with a large team on a large Angular application (at a well known global tech company), and are mostly in response to problems I witnessed during the development of this application.

In fairness to myself, even though I've only been working with Angular for about a year, I've been building software for over 10 years in various environments; embedded, mobile, desktop, and now web. This isn't my first "rodeo."

Also, I love building software. I love it. So I put a lot of my energy into deeply thinking through things, actually trying ideas out, being very critical of my own mental models around programming, and adjusting my values as I learn.

With that, take these rules as my personal set of rules. These are the rules that I myself stand by. Obviously, you are free to completely disagree and in any case I appreciate you even taking the time to read these.

Rules

Rule 1

Services should focus on the data while Components should focus on presenting that data.

Why?
The UI is complicated enough. No need to add business logic to that pile.

Rule 2

Services and Components should focus on one reasonable piece of data.

Why?
...Are you really asking? It's much easier to reason about code that focuses on one thing. And for the record, "one" doesn't have to mean that you break everything down into nano pieces - that's not reasonable. Be smart and intentional about choosing your "one" thing.

Rule 3

There are no "smart" or "dumb" Components; all Components do something specific and useful.

Why?
When you try to subcategorize in your architecture you get closer to just adding complexity with little to no value. Again, be reasonable.

Sub-Rules

Sub-Rule 1

Prefer Signals over Observables when applicable.

Why?
Both encourage declarative and (obviously) reactive code, but now that we have Signals the only sensible use for Observables is asynchronous work. Observables can be very complicated even in some simple cases. Signals can be very simple even in some complicated cases. Both are useful; be smart about which one you choose.

Sub-Rule 2

Prefer Standalone over Module-based Components.

Why?
One of the worst things about Angular is the "boilerplatiness" of it. Standalone Components makes this much less of an issue and provides some other benefits, namely the ability for a Component to manage its own dependencies instead of relying on a Module to manage the dependencies of many Components.

Syntax highlighting in editors is a pain in the ass. The way to prove this to yourself is to make your own syntax highlighting color theme for multiple editors.

The Problem

The fundamental way syntax highlighting is handled in editors today is to pick a specification format (like TextMate) and then hope that color theme authors follow "roughly" the same token/scope assignments. Editors also try to rely a little bit on LSPs to provide "better" tokens/scopes for highlighting.

The solutions so far try to treat all file formats generically, but this just doesn't work well - there are concepts in programming languages that just don't exist in simpler text files -- this is even the case between some programming languages, and again, we're trying to get them all to conform to the same set of generic "tokens."

A Possible Solution

Create a standard similar to LSP that focuses specifically on syntax highlighting, an HSP (highlight server protocol). Why not just use LSP? Because LSPs are supposed to provide language specific functionality like autocomplete and finding references, not syntax highlighting. Same goes for the HSP, its purpose is to provide information specifically for highlighting, not for language features.

From the HSP Author Perspective

This HSP would produce a set of tokens and token names that the editor would use specifically for highlighting.

From the LSP Author Perspective

The LSP author wouldn't have to worry about syntax highlighting at all anymore, just focus on the actual features of the language.

From the Color Theme Author Perspective

The color theme author would have a well defined set of tokens and token names to use when adding support for a file format. No more guessing

From the Editor Author Perspective

Use the HSP's tokens and token names to highlight the syntax, obviously. But what if an HSP isn't available? Well I guess it's up to the editor - fallback to something else or maybe just require an HSP.

We've all heard it, "design for maintainability" and "once we're in maintenance mode..." What exactly do we mean by this? When I hear this I hear, "let's keep our software exactly how it is" and "don't change it." In fact, I think this is exactly what we mean, but for some reason we subconsciously tell ourselves something slightly different.

This contradicts a fundamental attribute of software; change.

What we should be saying is "design for changeability." We want to be able to easily change our software at any time.

Before I go any further, if the word "flexibility" is coming to mind right now then ignore it. Although the word flexibility is about change it is not the same as changeability in the context I'm talking about. Flexibility in software is more about the ability to handle many scenarios, whereas changeability is more about the ability to change direction entirely.

How many times have you had to fix a bug or add a new feature to code that was just too rigid and fragile in its ways, you had no choice but to duct tape your solution to it? I bet the answer isn't 0.

So, how do we design for changeability?

Solve your problem

It all starts with understanding your problem and limiting your solution to only the essential parts of that problem. Inevitably, every problem can be broken down into bite-sized pieces and when you do this you'll see which of those pieces are more valuable than the others - take the big pieces and sweep the crumbs into the dustpan.

When you solve more than you need to, you add unnecessary complexity to your system and if you keep doing this then your system will become adverse to change.

Be focused

When designing the architecture of your solution keep the parts focused specifically on solving their part of the problem. Never give any of the parts more than one responsibility. For example, if the thing manages a piece of data and glues some other things together, take the glue part out and give that responsibility to another part of the architecture.

When you have more than one responsibility then you must also manage the coordination between them, which means you have yet another responsibility on top of your other responsibilities. Same goes for your software.