Why and What? Signals in Angular!

Because Angular, my friends, is Angular, and because it’s a Framework, not just a library, I felt it wasn’t great to rely on external stuff for state management… so they created Signals 🦧

Let’s take a step back before diving into Signals.

Angular used to rely on a mechanism called Dirty Checking, using the well-known library zone.js to track changes.

So, what was the problem?
Even if you changed a tiny value, Angular would check all components to see if anything changed—even when it wasn’t necessary 🦧

This meant a lot of unnecessary updates and poorer performance.

That’s where Signals come in.

Signals gradually eliminate zone.js and move Angular to Fine-Grained Reactivity, which is exactly how Signals work.
The idea is to make everything reactive in a smarter way:
🔫 If a value changes, only the part of the UI related to that value updates—no more scanning everything like before.

It’s important to know that Signals are basically an implementation of the Observer Design Pattern inside Angular.
Simply put:

You have Observables (the values)

And Observers (the UI pieces or code that care about those values)

As soon as the value changes, all relevant Observers are notified directly and update themselves immediately.
So instead of Angular checking the whole project asking “who changed what?”, the info goes straight to the Observers—who are chilling with a coffee ☕️.

That’s Signals in a nutshell!
If any term feels unclear, drop a comment and we’ll chat 😋

If you want a deeper dive on what it actually does, check out this post:
https://lnkd.in/dvFG2P3d