When Angular introduced Signals, I was excited…
but also confused.
kept asking myself:
How is this different from Observables?
When should I use signal()?
Why do we need computed()?
Is this just another reactive API?
Then one simple trick changed everything for me:
Stop thinking in streams. Start thinking in state.
The Mental Model Shift
Here’s the trick:
signal() = State
computed() = Derived State
That’s it.
Nothing more complicated.
Example:
ts count = signal(0);
doubleCount = computed(() => this.count() * 2);
How to think about it:
- count = the source of truth
- doubleCount = a calculation based on the truth
Just like real life:
- You store raw data
- You derive insights from that data
Why This Made Everything Clear
signal()
Holds state
Can be read
Can be updated
Triggers updates automatically
this.count.set(1);
this.count.update(v => v + 1);
It’s your single source of truth.
computed()
Never stores state
Only derives state
Recalculates automatically
Always stays in sync
doubleCount = computed(() => this.count() * 2);
You never update computed() manually.
It updates itself.
The Big Realization
Before, I was thinking:
- subscriptions
- streams
- emissions
- operators
- pipes
Now I think:
- state
- dependencies
- derivations
- reactivity graph
- automatic updates
Signals are not trying to replace Observables.
They are solving a different problem:
Simple, synchronous, local state management inside components.
How This Changed My Angular Design
Now I design components like this:
Signals → store state
Computed → derive state
Effects → react to state
Observables → async flows / APIs / streams
This separation makes my apps:
more predictable
easier to debug
easier to test
easier to scale
easier to reason about
Understanding Signals is not about learning new syntax.
It’s about learning a new way to think:
Data - State - Derivation - Reaction
Once you get that mental model,
signal() and computed() become natural.
And Angular suddenly feels… simpler
Top comments (0)