Why signals feel different
A signal is a value container Angular can track. A computed signal derives from other signals. An effect reacts when tracked values change.
The important win is traceability. Instead of spreading small UI state across subscriptions and lifecycle hooks, you can keep local state close to the component and make derived values obvious.
const query = signal("");
const users = signal<User[]>([]);
const filteredUsers = computed(() =>
users().filter((user) => user.name.includes(query()))
);Signals vs RxJS is the wrong fight
Use RxJS for streams, cancellation, websockets, complex async composition, and external event flows. Use signals for local state, derived UI values, and places where reading current state should be straightforward.
Real applications often use both. The boundary is the design decision.
Try the idea
Effects are for side effects, not hidden business logic
Effects are tempting because they run automatically. Keep them small. Use them for logging, syncing small local side effects, or bridging state to external APIs, not for burying core product behavior.
Production notes for Angular apps
Angular features stay maintainable when state ownership is obvious. Before adding another shared service or utility, decide whether the behavior belongs to a component, a feature boundary, an API service, or a reusable UI primitive.
The best Angular code is boring to navigate: feature folders are predictable, templates stay readable, and async behavior has a clear home instead of being scattered through lifecycle hooks.
Conclusion
Signals are strongest when they make state easier to see, not when they hide workflows behind automatic reactions.